home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft__misc / 1id-abstracts.txt < prev    next >
Text File  |  1997-11-02  |  735KB  |  12,871 lines
  1.               Current Internet-Drafts
  2.  
  3.      This summary sheet provides a short synopsis of each Internet-Draft
  4. available within the "internet-drafts" directory at the shadow
  5. sites directory.  These drafts are listed alphabetically by working
  6. group acronym and start date.
  7.  
  8.  
  9. The Internet and the Millennium Problem (2000)
  10. ----------------------------------------------
  11.  
  12.   "The Internet and the Millenium Problem (Year 2000)", Philip Nesser II, 
  13.   08/04/1997, <draft-ietf-2000-issue-00.txt>                               
  14.  
  15.        The Year 2000 Working Group(WG) has conducted an investigation into
  16.        the millenium problem as it regards Internet related protocols.
  17.        This investigation only targeted the protocols as documented in the
  18.        Request For Comments Series (RFCs).  This investigation discovered
  19.        little reason for concern with regards to the functionality of the
  20.        protocols.  A few minor cases of older implementations still using
  21.        two digit years (ala RFC 850) were discovered, but almost all
  22.        Internet protocols were given a clean bill of health.  Several cases
  23.        of 'period' problems were discussed where a time field would 'roll
  24.        over' as the size of field was reached.  In particular, there are
  25.        several protocols which have 32 bit signed integer representations
  26.        of the number of seconds since January 1, 1970 which will turn
  27.        negative at Tue Jan 19 03:14:07 GMT 2038.  Areas whose protocols
  28.        will be effected by such problems have been notified so that new
  29.        revisions will remove this limitation.
  30.                                                                            
  31.  
  32. Application Configuration Access Protocol (acap)
  33. ------------------------------------------------
  34.  
  35.   "ACAP -- Application Configuration Access Protocol", C Newman, J Myers, 
  36.   08/26/1997, <draft-ietf-acap-spec-06.txt>                                
  37.  
  38.     The Application Configuration Access Protocol (ACAP) is designed to
  39.        support remote storage and access of program option, configuration
  40.        and preference information.  The data store model is designed to
  41.        allow a client relatively simple access to interesting data, to 
  42.     allow
  43.        new information to be easily added without server re-configuration,
  44.        and to promote the use of both standardized data and custom or
  45.        proprietary data.  Key features include 'inheritance' which can be
  46.        used to manage default values for configuration settings and access
  47.        control lists which allow interesting personal information to be
  48.        shared and group information to be restricted.                      
  49.  
  50.   "ACAP TYPE Extension", R. Earhart, 04/23/1997, 
  51.   <draft-ietf-acap-type-ext-00.txt>                                        
  52.  
  53.     The Application Configuration Access Protocol [ACAP] defines rough 
  54.     typing information in the form of an attribute naming convention.  This
  55.     extension to ACAP allows a MIME content-type/subtype with parameters to
  56.     be associated with a given piece of data, providing knowledgeable 
  57.     clients with useful information in a way which maintains compatability 
  58.     with innocent clients and servers.                                     
  59.  
  60.   "ACAP Datatyping and Datatyping Discovery", J. De Winter, 04/25/1997, 
  61.   <draft-ietf-acap-dewinter-dtype-00.txt>                                  
  62.  
  63.     The Application Configuration Access Protocol (ACAP) is designed to 
  64.     support remote storage and access of program option, configuration and 
  65.     preference information.  In certain circumstances, it is desirable or 
  66.     necessary to deal with information that has a limit imposed on it. 
  67.     While the general ACAP specification does provide for a (SYNTAX) alert 
  68.     to inform the submittor that the stored information was not in a valid 
  69.     syntax for that field, there is no generic method to discover that 
  70.     syntax.            There is strong feeling in the ACAP working group 
  71.     that variable length strings should be used for data where possible, 
  72.     but there is also the knowledge that ACAP will be used to configure and
  73.     access existing systems where the use of such variable length strings 
  74.     may be difficult or impossible.                                        
  75.  
  76.   "Multi-Lingual String Format (MLSF)", C Newman, 06/09/1997, 
  77.   <draft-ietf-acap-mlsf-01.txt>                                            
  78.  
  79.     The IAB charset workshop [IAB-CHARSET] concluded that for human 
  80.     readable text there should always be a way to specify the natural 
  81.     language.  Many protocols are designed with an attribute-value model 
  82.     (including RFC 822, HTTP, LDAP, SNMP, DHCP, and ACAP) which stores many
  83.     small human readable text strings.  The primary function of an 
  84.     attribute-value model is to simplify both extensibility and 
  85.     searchability.  A solution is needed to provide language tags in these 
  86.     small human readable text strings, which does not interfere with these 
  87.     primary functions.                           This specification defines
  88.     MLSF (Multi-Lingual String Format) which applies another layer of 
  89.     encoding on top of UTF-8 [UTF-8] to permit the addition of language 
  90.     tags anywhere within a text string.  In addition, it defines an 
  91.     alternate form which can be used to include alternative representations
  92.     of the same text in different character sets.  MLSF has the property 
  93.     that UTF-8 is a proper subset of MLSF. This preserves the searchability
  94.     requirement of the attribute-value model. Appendix F of this document 
  95.     includes a brief discussion of the background behind MLSF and why some 
  96.     other potential solutions were rejected for this purpose.              
  97.  
  98.   "Anonymous SASL Mechanism", C Newman, 08/26/1997, 
  99.   <draft-ietf-acap-anon-01.txt>                                            
  100.  
  101.          It is common practice on the Internet to permit anonymous access 
  102.     to
  103.          various services.  Traditionally, this has been done with a plain
  104.          text password mechanism using 'anonymous' as the user name and
  105.          optional trace information, such as an email address, as the
  106.          password.  As plaintext login commands are not permitted in new
  107.          IETF protocols, a new way to provide anonymous login is needed
  108.          within the context of the SASL [SASL] framework.
  109.                                                                            
  110.  
  111.   "Two Alternative Proposals for Language Taging in ACAP", M. Duerst, 
  112.   06/23/1997, <draft-ietf-acap-langtag-00.txt>                             
  113.  
  114.     For various computing applications, it is helpful to know the language 
  115.     of the text being processed. This can be the case even if otherwise 
  116.     only pure character sequences (so-called plain text) are handled.  From
  117.     several sides, the need for such a scheme for ACAP has been claimed. 
  118.     One specific scheme, called MLSF, has also been proposed, see 
  119.     draft-ietf-acap-mlsf-01.txt for details.  This document proposes two 
  120.     alternatives to MLSF. One alternative is using text/enriched-like 
  121.     markup.  The second alternative is using a special tag-introduction 
  122.     character.  Advantages and disadvantages of the various proposals are 
  123.     discussed. Some general comments about the topic of language tagging 
  124.     are given in the introduction.                                         
  125.  
  126.   "ACAP Authorization Identifier Datasets", S. Hole, 07/24/1997, 
  127.   <draft-ietf-acap-authid-00.txt>                                          
  128.  
  129.     Most distributed (client/server) applications require an authentication
  130.     process between the client and the server before the server will grant 
  131.     access to its managed resources.  Many applications provide varying 
  132.     levels of access to server resources based on a combination of 
  133.     authentication credentials and access control rules.   The collection 
  134.     of information used to control access to resources is called 
  135.     'authorization information'.                                           
  136.  
  137.   "ACAP Personal Addressbook Dataset Class", C Newman, 07/29/1997, 
  138.   <draft-ietf-acap-abook-00.txt>                                           
  139.  
  140.          IMAP [IMAP4] allows nomadic users to access their mailstore from
  141.          any client, but it does not support storage of personal
  142.          addressbooks.  Application Configuration Access Protocol [ACAP]
  143.          provides an ideal mechanism for storage of personal addressbooks.
  144.          While ACAP permits the definition of vendor specific solutions to
  145.          this problem, having a standard addressbook dataset class permits
  146.          clients from different vendors to interoperably share the same
  147.          personal addressbooks.  This specification defines a standard
  148.          dataset class for personal addressbooks.
  149.      
  150.          Personal addressbooks differ from white pages services because all
  151.          the attributes and entries are controlled by the user who owns the
  152.          addressbook rather than a directory administrator.  The user or 
  153.     the
  154.          clients he uses may add new attributes at any time and some of
  155.          these attributes are not suitable for a white pages service.
  156.                                                                            
  157.  
  158.   "ACAP personal options dataset class", S. Hole, 07/30/1997, 
  159.   <draft-ietf-acap-options-01.txt>                                         
  160.  
  161.          The Application Configuration Access Protocol (ACAP) is designed 
  162.     to
  163.          support remote storage and access of application option,
  164.          configuration and preference information.  The generalized form of
  165.          this runtime configuration is called 'options'.  Options consist
  166.          consist of any type of structured or unstructured data that an
  167.          application requires to operate in a user specific manner.
  168.                                                                            
  169.  
  170. Authenticated Firewall Traversal (aft)
  171. --------------------------------------
  172.  
  173.   "Challenge-Handshake Authentication Protocol for SOCKS V5", M. 
  174.   VanHeyningen, 03/20/1997, <draft-ietf-aft-socks-chap-00.txt>             
  175.  
  176.     This document specifies the integration of the Challenge-Handshake 
  177.     Authenticaton Protocol (CHAP) [RFC 1994] into SOCKS Version 5 [RFC 
  178.     1928].  It is intended to provide a simple, lightweight authentication 
  179.     method which is more secure than cleartext passwords but simpler than 
  180.     GSSAPI-based methods.  This document describes the message formats and 
  181.     protocol details of incorporating CHAP into the SOCKS V5 authentication
  182.     'subnegotiation.'  Support is included for authentication of server to 
  183.     client as well as client to server.                                    
  184.  
  185.   "Challenge-Response Authentication Method for SOCKS V5", M. VanHeyningen,
  186.   03/20/1997, <draft-ietf-aft-socks-cram-00.txt>                           
  187.  
  188.     This document specifies a general Challenge-Response Authentication 
  189.     Method (CRAM) for use with SOCKS Version 5 [RFC 1928].  It is intended 
  190.     to support various challenge-response mechanisms, such as S/KEY and OTP
  191.     [RFC 1938] as well as authentication tokens.                           
  192.  
  193.   "Secure Sockets Layer for SOCKS Version 5", M. VanHeyningen, 03/20/1997, 
  194.   <draft-ietf-aft-socks-ssl-00.txt>                                        
  195.  
  196.     This document specifies the use of SSL 3.0 and possible successor 
  197.     protocols as an authentication method for SOCKS Version 5.  The design 
  198.     is similar to, and largely derived from, the integration of GSS-API 
  199.     into SOCKS5 [RFC 1961].  A framework is provided for future extensions,
  200.     and the use of other 'subauthentication' methods inside SSL is 
  201.     supported.                                                             
  202.  
  203.   "SOCKS Protocol Version 5", William Perry, 07/30/1997, 
  204.   <draft-ietf-aft-socks-pro-v5-01.txt>                                     
  205.  
  206.     The use of network firewalls, systems that effectively isolate an 
  207.     organizations internal network structure from an exterior network, such
  208.     as the INTERNET is becoming increasingly popular.                      
  209.  
  210.   "Feature Discovery: A Generic Extension Mechanism for SOCKS Version 5", 
  211.   M. VanHeyningen, 07/23/1997, <draft-ietf-aft-socks-ext-00.txt>           
  212.  
  213.     This document specifies a command extension to the SOCKS Version 5 
  214.     protocol which enables compliant clients to discover features supported
  215.     by the server.  After discovering the support of such features, the 
  216.     client may use them in subsequent connections to that server.  This 
  217.     mechanism does not provide for negotiation; it is a way of instructing 
  218.     the client what features the server supports, not establishing which 
  219.     features the client supports or wishes to use.                         
  220.  
  221. SNMP Agent Extensibility (agentx)
  222. ---------------------------------
  223.  
  224.   "Agent Extensibility (AgentX) Protocol  Version 1", Bert Wijnen, D. 
  225.   Francisco, M. Daniele, 06/10/1997, <draft-ietf-agentx-ext-pro-04.txt>    
  226.  
  227.     This memo defines a standardized framework for extensible SNMP agents. 
  228.     It defines processing entities called master agents and subagents, a 
  229.     protocol (AgentX) used to communicate between them, and the elements of
  230.     procedure by which the extensible agent processes SNMP protocol 
  231.     messages.                                                              
  232.  
  233.   "Definitions of Managed Objects for Extensible SNMP Agents", M. Greene, 
  234.   S. Gudur, 05/15/1997, <draft-ietf-agentx-mib-00.txt>                     
  235.  
  236.     This memo defines an experimental portion of the Management Information
  237.     Base (MIB) for use with network management protocols in the Internet 
  238.     community.  In particular, it describes objects managing SNMP agents 
  239.     that use the Agent Extensibility (AgentX) Protocol.                    
  240.     This memo specifies a MIB module in a manner that is both compliant to 
  241.     the SNMPv2 SMI, and semantically identical to the peer SNMPv1 
  242.     definitions.                                                           
  243.  
  244. Application MIB (applmib)
  245. -------------------------
  246.  
  247.   "Definitions of System-Level Managed Objects for Applications", Jonathan 
  248.   Saperia, Cheryl Krupczak, 10/31/1997, 
  249.   <draft-ietf-applmib-sysapplmib-09.txt>                                   
  250.  
  251.      This memo defines a portion of the Management Information Base
  252.      (MIB) for use with network management protocols in the
  253.      Internet community. In particular, it describes a basic set of
  254.      managed objects for fault, configuration and performance
  255.      management of applications from a systems perspective.  More
  256.      specifically, the managed objects are restricted to
  257.      information that can be determined from the system itself and
  258.      which does not require special instrumentation within the
  259.      applications to make the information available.
  260.      
  261.      This memo does not specify a standard for the Internet
  262.      community.                                                            
  263.  
  264.   "Definitions of Managed Objects for WWW Services", C. Kalbfleisch, H. 
  265.   Hazewinkel, J. Schoenwaelder, 09/26/1997, 
  266.   <draft-ietf-applmib-wwwmib-05.txt>                                       
  267.  
  268.        This memo defines an experimental portion of the Management
  269.        Information Base (MIB) for use with network management protocols in
  270.        the Internet Community. In particular it describes a set of objects
  271.        for managing World-Wide Web (WWW) services. This MIB extends the
  272.        application management framework defined by the System Application
  273.        Management MIB (SYSAPPL-MIB) and the Application Management MIB
  274.        (APPLICATION-MIB). The protocol statistics defined in the WWW 
  275.     Service
  276.        MIB are based on an abstract document transfer protocol (DTP). This
  277.        memo also defines a mapping of the abstract DTP to HTTP and FTP.
  278.        Additional mappings may be defined in the future in order to use 
  279.     this
  280.        MIB with other document transfer protocols. It is anticipated that
  281.        such future mappings will be defined in separate RFCs.              
  282.  
  283.   "Application Management MIB", Jonathan Saperia, Cheryl Krupczak, Randy 
  284.   Presuhn, C. Kalbfleisch, 08/04/1997, <draft-ietf-applmib-mib-04.txt>     
  285.  
  286.     This memo defines an experimental portion of the Management Information
  287.     Base (MIB) for use with network management protocols in the Internet 
  288.     Community.  In particular, it defines objects used for the management 
  289.     of applications.  This MIB complements the System Application MIB, 
  290.     providing for the management of applications' common attributes which 
  291.     could not typically be observed without the cooperation of the software
  292.     being managed.                                                         
  293.  
  294. Access, Searching and Indexing of Directories (asid)
  295. ----------------------------------------------------
  296.  
  297.   "A MIME Content-Type for Directory Information", Tim Howes, Mark Smith, 
  298.   07/24/1997, <draft-ietf-asid-mime-direct-04.txt>                         
  299.  
  300.     This document defines a MIME Content-Type for holding directory 
  301.     information.  The definition is independent of any particular directory
  302.     service or protocol.  The text/directory Content-Type is defined for 
  303.     holding a variety of directory information, for example, name, or email
  304.     address, or logo. The text/directory Content-Type can also be used as 
  305.     the root body part in a multipart/related Content-Type for handling 
  306.     more complicated situations, especially those in which non-textual 
  307.     information that already has a natural MIME representation, for 
  308.     example, a photograph or sound, must be represented.  The 
  309.     text/directory Content-Type defines a general framework and format for 
  310.     holding directory information in a simple 'type: value' form.  
  311.     Mechanisms are defined to specify alternate character sets, languages, 
  312.     encodings and other meta-information.  This document also defines the 
  313.     procedure by which particular formats,  called profiles, for carrying 
  314.     application-specific information within a text/directory Content-Type 
  315.     may be defined and registered, and the conventions such formats must 
  316.     follow. It is expected that other documents will be produced that 
  317.     define such formats for various applications (e.g., white pages).      
  318.  
  319.   "A Simple Caching Scheme for LDAP and X.500 Directories", Tim Howes, L. 
  320.   Howard, 10/22/1997, <draft-ietf-asid-ldap-cache-01.txt>                  
  321.  
  322.     This memo defines an object class and attribute type  in  support  of  
  323.     a
  324.     simple  caching  mechanism  for  use in LDAP and X.500 directories.  
  325.     The
  326.     object class allows a simple 'time-to-live' attribute to be included  
  327.     in
  328.     entries,  enabling  clients  retrieving  the  attribute to tell when 
  329.     the
  330.     other information they have retrieved from the entry  should  be  
  331.     thrown
  332.     away.  The  use of this scheme does not preclude the subsequent or 
  333.     addi-
  334.     tional use of other more complicated schemes, for example, allowing 
  335.     dif-
  336.     ferent TTLs on individual attributes.                                  
  337.  
  338.   "WHOIS++ URL Specification", M. Hamilton, 05/15/1997, 
  339.   <draft-ietf-asid-whois-url-01.txt>                                       
  340.  
  341.     This document defines a new Uniform Resource Locator (URL) scheme 
  342.     'whois++', which provides a convention within the URL framework for 
  343.     referring to WHOIS++ servers and the data held within them.            
  344.  
  345.   "Lightweight Directory Access Protocol (v3)", Steve Kille, Tim Howes, M. 
  346.   Wahl, 10/20/1997, <draft-ietf-asid-ldapv3-protocol-08.txt>               
  347.  
  348.     The protocol described in this document is designed to provide access
  349.        to directories supporting the X.500 models, while not incurring the
  350.        resource requirements of the X.500 Directory Access Protocol (DAP).
  351.        This protocol is specifically targeted at management applications 
  352.     and
  353.        browser applications that provide read/write interactive access to
  354.        directories. When used with a directory supporting the X.500
  355.        protocols, it is intended to be a complement to the X.500 DAP.      
  356.  
  357.   "Lightweight Directory Access Protocol (v3):  Attribute Syntax 
  358.   Definitions", Steve Kille, Tim Howes, M. Wahl, A. Coulbeck, 10/20/1997, 
  359.   <draft-ietf-asid-ldapv3-attributes-08.txt>                               
  360.  
  361.     The Lightweight Directory Access Protocol (LDAP) [1] requires that the 
  362.     contents of AttributeValue fields in protocol elements be octet 
  363.     strings.  This document defines a set of syntaxes for LDAPv3, and the 
  364.     rules by which attribute values of these syntaxes are represented as 
  365.     octet strings for transmission in the LDAP protocol.  The syntaxes 
  366.     defined in this document are referenced by this and other documents 
  367.     that define attribute types.  This document also defines the set of 
  368.     attribute types which LDAP servers should support.                     
  369.  
  370.   "vCard MIME Directory Profile", Tim Howes, F. Dawson, 08/02/1997, 
  371.   <draft-ietf-asid-mime-vcard-03.txt>                                      
  372.  
  373.        This memo defines the profile of the MIME Content-Type [MIME-DIR] 
  374.     for
  375.        directory information for a white-pages person object, based on a
  376.        vCard electronic business card. The profile definition is 
  377.     independent
  378.        of any particular directory service or protocol. The profile is
  379.        defined for representing and exchanging a variety of information
  380.        about an individual (e.g., formatted and structured name and 
  381.     delivery
  382.        addresses, email address, multiple telephone numbers, photograph,
  383.        logo, audio clips, etc.). The directory information used by this
  384.        profile is based on the attributes for the person object defined in
  385.        the X.520 and X.521 directory services recommendations. The profile
  386.        also provides the method for including a [VCARD] representation of a
  387.        white-pages directory entry within the MIME Content-Type defined by
  388.        the [MIME-DIR] document.
  389.                                                                            
  390.  
  391.   "Lightweight Directory Access Protocol (v3):  Extensions for Dynamic 
  392.   Directory Services", Tony Genovese, M. Wahl, Y. Yaacovi, 09/29/1997, 
  393.   <draft-ietf-asid-ldapv3-dynamic-06.txt>                                  
  394.  
  395.        This document defines the requirements for dynamic directory 
  396.     services
  397.        and specifies the format of request and response extended operations
  398.        for supporting client-server interoperation in a dynamic directories
  399.        environment. 
  400.      
  401.        The Lightweight Directory Access Protocol (LDAP) [1] supports
  402.        lightweight access to static directory services, allowing relatively
  403.        fast search and update access.  Static directory services store
  404.        information about people that persists in its accuracy and value 
  405.     over
  406.        a long period of time.
  407.       
  408.        Dynamic directory services are different in that they store
  409.        information that only persists in its accuracy and value when it is
  410.        being periodically refreshed.  This information is stored as dynamic
  411.        entries in the directory.  A typical use will be a client or a 
  412.     person
  413.        that is either online - in which case it has an entry in the
  414.        directory, or is offline - in which case its entry disappears from 
  415.     the
  416.        directory.  Though the protocol operations and attributes used by
  417.        dynamic directory services are similar to the ones used for static
  418.        directory services, clients that store dynamic information in the
  419.        directory need to periodically refresh this information, in order to
  420.        prevent it from disappearing.  If dynamic entries are not refreshed
  421.        within a given timeout, they will be removed from the directory.  
  422.     For
  423.        example, this will happen if the client that set them goes offline.
  424.      
  425.        A flow control mechanism from the server is also described that 
  426.     allows
  427.        a server to inform clients how often they should refresh their
  428.        presence.                                                           
  429.  
  430.   "Lightweight Directory Access Protocol (v3): UTF-8 String Representation 
  431.   of Distinguished Names", Steve Kille, Tim Howes, M. Wahl, 04/30/1997, 
  432.   <draft-ietf-asid-ldapv3-dn-03.txt>                                       
  433.  
  434.     The X.500 Directory uses distinguished names as the primary keys to 
  435.     entries in the directory.  Distinguished Names are encoded in ASN.1 in 
  436.     the X.500 Directory protocols.  In the Lightweight Directory Access 
  437.     Protocol, a string representation of distinguished names is 
  438.     transferred.  This specification defines the string format for 
  439.     representing names, which is designed to give a clean representation of
  440.     commonly used distinguished names, while being able to represent any 
  441.     distinguished name.                                                    
  442.  
  443.   "Using Domains in LDAP/X.500 Distinguished Names", Steve Kille, Rick 
  444.   Huber, Sri Sataluri, A. Grimstad, M. Wahl, 09/12/1997, 
  445.   <draft-ietf-asid-ldap-domains-02.txt>                                    
  446.  
  447.     The Lightweight Directory Access Protocol (LDAP) uses X.500-compatible
  448.        distinguished names [3] for providing unique identification of 
  449.     entries.
  450.          
  451.        This document defines an algorithm by which a name registered with 
  452.     the
  453.        Internet Domain Name Service [2] can be represented as an LDAP
  454.        distinguished name.                                                 
  455.  
  456.   "Use of Language Codes in LDAPv3", Tim Howes, M. Wahl, 06/06/1997, 
  457.   <draft-ietf-asid-ldapv3-lang-02.txt>                                     
  458.  
  459.     The Lightweight Directory Access Protocol [1] provides a means for 
  460.     clients to interrogate and modify information stored in a distributed 
  461.     directory system.  The information in the directory is maintained as 
  462.     attributes [2] of entries.  Most of these attributes have syntaxes 
  463.     which are human-readable strings, and it is desirable to be able to 
  464.     indicate the natural language associated with attribute values.        
  465.     This document describes how language codes [3] are carried in LDAP and 
  466.     are to be interpreted by LDAP servers.  All implementations MUST be 
  467.     prepared to accept language codes in the LDAP protocols.  Servers may 
  468.     or may not be capable of storing attributes with language codes in the 
  469.     directory.                                                             
  470.  
  471.   "The LDAP Data Interchange Format (LDIF) - Technical Specification", G. 
  472.   Good, 07/25/1997, <draft-ietf-asid-ldif-02.txt>                          
  473.  
  474.     This document describes a file format suitable for describing directory
  475.     information or modifications made to directory information.  The file 
  476.     format, known as LDIF, for LDAP Data Interchange Format, is typically 
  477.     used to import and export directory information between LDAP-based 
  478.     directory servers, or to describe a set of changes which are to be 
  479.     applied to a directory.                                                
  480.     There are a number of situations where a common interchange format is 
  481.     desirable.  For example, one might wish to export a copy of the 
  482.     contents of a directory server to a file, move that file to a different
  483.     machine, and import the contents into a second directory server.    
  484.     Additionally, by using a well-defined interchange format, development 
  485.     of data import tools from legacy systems is facilitated.  A fairly 
  486.     simple set of tools written in awk or perl can, for example, convert a 
  487.     database of personnel information into an LDIF file, which can then be 
  488.     imported into a directory server, regardless of the internal database 
  489.     representation the target directory server uses.   The key words 
  490.     'MUST', 'MAY', and 'SHOULD' used in this document are to be interpreted
  491.     as described in [7].                                                   
  492.  
  493.   "WHOIS++ templates", J. Knight, Patrik Faltstrom, M. Hamilton, Leslie 
  494.   Daigle, 10/03/1997, <draft-ietf-asid-whois-schema-02.txt>                
  495.  
  496.          WHOIS++ is a simple Internet search and retrieval protocol,
  497.          specified in RFC 1835, which allows clients and servers to 
  498.     exchange
  499.          structured data objects known as templates.  In the interests of
  500.          interoperability it is desirable to have a common base schema for
  501.          these templates.  This document suggests a schema drawn from
  502.          implementation and deployment experience to date with WHOIS++.
  503.      
  504.                                                                            
  505.  
  506.   "Definition of the inetOrgPerson Object Class", Mark Smith, 08/05/1997, 
  507.   <draft-ietf-asid-inetorgperson-01.txt>                                   
  508.  
  509.     While the X.500 standards [X500] define many useful attribute types and
  510.     object classes, they do not define a person object class that meets the
  511.     requirements found in today's Internet and Intranet directory service
  512.     deployments.  We define a new object class called inetOrgPerson that
  513.     extends the X.521 standard organizationalPerson class to meet these
  514.     needs.                                                                 
  515.  
  516.   "Architecture of the WHOIS++ service", Chris Weider, Peter Deutsch, 
  517.   Patrik Faltstrom, R. Schoultz, Leslie Daigle, S. Newell, 03/26/1997, 
  518.   <draft-ietf-asid-whoispp-01.txt>                                         
  519.  
  520.     This document describes Whois++, an extension to the trivial WHOIS 
  521.     service described in RFC 954 to permit WHOIS-like servers to make 
  522.     available more structured information to the Internet.  We describe an 
  523.     extension to the simple WHOIS data model and query protocol and a 
  524.     companion extensible, distributed indexing service.  A number of 
  525.     options have also been added such as the use of multiple languages and 
  526.     character sets, more advanced search expressions, structured data and a
  527.     number of other useful features.  An optional authentication mechanism 
  528.     for protecting all or part of the associated Whois++ information 
  529.     database from unauthorized access is also described.                   
  530.  
  531.   "Definition of an Object Class to Hold LDAP Change Records", G. Good, 
  532.   07/25/1997, <draft-ietf-asid-changelog-01.txt>                           
  533.  
  534.     In order to support more flexible replication methods, it is desirable 
  535.     to specify some manner in which an LDAP client may retrieve a set of 
  536.     changes which have been applied to an LDAP server's database.  The 
  537.     client, which may be another LDAP server, may then choose to update its
  538.     own replicated copy of the data.  This document specifies an object 
  539.     class which may be used to represent changes applied to an LDAP server.
  540.     It also specifies a method for discovering the location of the 
  541.     container object which holds these change records, so that clients and 
  542.     servers have a common rendezvous point for this information.           
  543.  
  544.   "LDAP Control Extension for Simple Paged Results Manipulation", Chris 
  545.   Weider, Tim Howes, A. Herron, 03/26/1997, 
  546.   <draft-ietf-asid-ldapv3-simplepaged-01.txt>                              
  547.  
  548.     This document describes an LDAPv3 control extension for simple paging 
  549.     of search results. This control extension allows a client to control 
  550.     the rate at which an LDAP server returns the results of an LDAP search 
  551.     operation. This control may be useful when the LDAP client has limited 
  552.     resources and may not be able to process the entire result set from a 
  553.     given LDAP query, or when the LDAP client is connected over a 
  554.     low-bandwidth connection. Other operations on the result set are not 
  555.     defined in this extension. This extension is not designed to provide 
  556.     more sophisticated result set management.           The key words 
  557.     'MUST', 'SHOULD', and 'MAY' used in this document are to be interpreted
  558.     as described in [bradner97].                                           
  559.  
  560.   "Lightweight Directory Access Protocol:  Schema for Storing RPC Entries 
  561.   in a Directory Service", P. Leach, S. Judd, S. Thatte, W. Hopkins, 
  562.   03/03/1997, <draft-ietf-asid-ldap-rpcschema-00.txt>                      
  563.  
  564.     The Lightweight Directory Access Protocol [1][2] defines a standard 
  565.     protocol for accessing diverse directory services. One common use of a 
  566.     directory service is the location of application services, among which 
  567.     are RPC services.                                                      
  568.     This document defines a set of object classes and attributes for 
  569.     storing metadata and binding information for RPC services that are 
  570.     DCE-compliant or closely follow the DCE model, in directories that 
  571.     support LDAP.                                                          
  572.  
  573.   "LDAP Multi-master Replication Protocol", Chris Weider, J. Strassner, 
  574.   07/31/1997, <draft-ietf-asid-ldap-mult-mast-rep-01.txt>                  
  575.  
  576.     This paper defines a multi-master, incremental replication protocol
  577.     using the LDAP protocol [LDAPv3]. This protocol uses and builds upon
  578.     previous LDAP support protocols, namely the changelog [change] and LDIF
  579.     [LDIF] protocols. It defines the use of two types of transport 
  580.     protocols
  581.     for replication data, and specifies the schema that must be supported 
  582.     by
  583.     a server that wishes to participate in replication activities using 
  584.     this
  585.     protocol.
  586.                                                                            
  587.  
  588.   "The LDAP URL Format", Tim Howes, Mark Smith, 08/21/1997, 
  589.   <draft-ietf-asid-ldapv3-url-04.txt>                                      
  590.  
  591.     LDAP is the Lightweight Directory Access Protocol, defined in  [1],  
  592.     [2] and  [3].  This document describes a format for an LDAP Uniform 
  593.     Resource Locator.  The format describes an LDAP search operation to 
  594.     perform to retrieve information from an LDAP directory. This document 
  595.     replaces RFC1959. It updates the LDAP URL format for version 3 of LDAP 
  596.     and clarifies how LDAP URLs are resolved.  This document also defines 
  597.     an extension mechanism for LDAP URLs, so that future documents can 
  598.     extend their functionality, for example, to provide access to new 
  599.     LDAPv3 extensions as they are defined.                                 
  600.     The key words 'MUST', 'MAY', and 'SHOULD' used in this document are to 
  601.     be interpreted as described in [6].                                    
  602.  
  603.   "The String Representation of LDAP Search Filters", Tim Howes, 
  604.   10/20/1997, <draft-ietf-asid-ldapv3-filter-03.txt>                       
  605.  
  606.     The Lightweight Directory Access Protocol (LDAP) [1] defines a network 
  607.     representation of a search filter transmitted to an LDAP server.  Some 
  608.     applications may find it useful to have a common way of representing 
  609.     these search filters in a human-readable form.  This document defines a
  610.     human-readable string format for representing LDAP search filters.     
  611.     This document replaces RFC 1960, extending the string LDAP filter 
  612.     definition to include support for LDAP version 3 extended match 
  613.     filters, and including support for representing the full range of 
  614.     possible LDAP search filters.                                          
  615.  
  616.   "LDAP-based Routing of SMTP Messages: Approach Used by Netscape", H. 
  617.   Lachman, 03/26/1997, <draft-ietf-asid-email-routing-ns-00.txt>           
  618.  
  619.     Directory services based on the Lightweight Directory Access Protocol 
  620.     (LDAP) [1] and X.500 [2] provide a general-purpose means to store 
  621.     information about users and other network entities.  One of the many 
  622.     possible uses of a directory service is to store information about 
  623.     users' email accounts, such as their email addresses, and how messages 
  624.     addressed to them should be routed.  In the interest of 
  625.     interoperability, it is desirable to have a common schema for such 
  626.     email-related information.      This document discusses some of the 
  627.     fundamental questions to be considered in the development of a common 
  628.     schema for LDAP-based routing of SMTP [3] messages, presents an 
  629.     approach that has been implemented and deployed, and discusses possible
  630.     extensions to that approach that may serve to make it more complete and
  631.     general.  The intent is to provide information about an existing 
  632.     implementation, and to stimulate discussion about whether and how to 
  633.     standardize the relevant aspects of LDAP-based messaging management.   
  634.  
  635.   "LDAP-based Routing of SMTP Messages: Approach at Stanford University", 
  636.   J. Hodges, B. Bense, 03/27/1997, 
  637.   <draft-ietf-asid-email-routing-su-00.txt>                                
  638.  
  639.     The 'Internet X.500 Schema' defines an RFC-822 email address attribute 
  640.     of a person's entry, rfc822Mailbox (aka 'Mail'), but it does not 
  641.     address the issues involved in routing RFC-822-based email within an 
  642.     administrative domain served by an X.500/LDAP-based directory service. 
  643.     Significantly, it doesn't delineate between a person's publicaly 
  644.     'advertised' or 'promoted' email address and the actual 'internal to 
  645.     the administrative domain' address for the person.                     
  646.     This memo illustrates an object class and an attendant attribute we use
  647.     at Stanford University to solve this issue. This scheme provides us 
  648.     with flexible, simple to implement, distributed routing of 
  649.     RFC-822-based email to people represented by entries within our 
  650.     directory service. The LDAP-enabled version of sendmail we use is 
  651.     freely available.               Additionally, we anticipate that the 
  652.     Internet community will devise conventions and perhaps support a 
  653.     process for facilitating multi-vendor directory utilization. We present
  654.     an anticipated tenet and goals.                                        
  655.  
  656.   "X.500 Strong Authentication Mechanisms for LDAPv3", M. Wahl, 03/27/1997,
  657.   <draft-ietf-asid-ldapv3-strong-00.txt>                                   
  658.  
  659.     This document defines two SASL [1] authentication mechanisms which may 
  660.     be used with LDAPv3 [2].  These mechanisms are only for authentication,
  661.     they have no effect on the protocol encodings and are not designed to 
  662.     provide integrity or confidentiality services.                         
  663.  
  664.   "A Summary of the Pilot X.500 Schema for use in LDAPv3", M. Wahl, 
  665.   03/27/1997, <draft-ietf-asid-schema-pilot-00.txt>                        
  666.  
  667.     This document provides an overview of attribute types and object 
  668.     classes for use in piloting directory services based on X.500 and LDAP.
  669.  
  670.   "A Summary of the X.500(96) User Schema for use with LDAPv3", M. Wahl, 
  671.   10/20/1997, <draft-ietf-asid-ldapv3schema-x500-03.txt>                   
  672.  
  673.     This document provides an overview of the attribute types and object 
  674.     classes defined by the ISO and ITU-T committees in the X.500 documents,
  675.     in particular those intended for use by directory clients.  This is the
  676.     most widely used schema for LDAP/X.500 directories, and many other 
  677.     schema definitions for white pages objects use it as a basis.  This 
  678.     document does not cover attributes used for the administration of X.500
  679.     directory servers, nor does it include attributes defined by other 
  680.     ISO/ITU-T documents.                                                   
  681.  
  682.   "LDAP Control Extension for Server Side Sorting of Search Results", Tim 
  683.   Howes, M. Wahl, A. Herron, 04/17/1997, 
  684.   <draft-ietf-asid-ldapv3-sorting-00.txt>                                  
  685.  
  686.     This document describes two LDAPv3 control extensions for server side 
  687.     sorting of search results. These controls allows a client to specify 
  688.     the attribute types and matching rules a server should use when 
  689.     returning the results to an LDAP search request.  The controls may be 
  690.     useful when the LDAP client has limited functionality or for some other
  691.     reason cannot sort the results but still needs them sorted.  Other 
  692.     permissible controls on search operations are not defined in this 
  693.     extension.           The sort controls allow a server to return a 
  694.     result code for the sorting of the results that is independent of the 
  695.     result code returned for the search operation.                         
  696.     The key words 'MUST', 'SHOULD', and 'MAY' used in this document are to 
  697.     be interpreted as described in [bradner97].                            
  698.  
  699.   "Referrals and Knowledge References in LDAP Directories", Tim Howes, M. 
  700.   Wahl, 05/01/1997, <draft-ietf-asid-ldapv3-referral-00.txt>               
  701.  
  702.     This document defines a 'ref' attribute and associated 'referral' 
  703.     object class for representing generic knowledge information in LDAP 
  704.     directories [LDAP].  The attribute uses URIs [RFC1738] to represent 
  705.     knowledge, enabling LDAP and non-LDAP services alike to be referenced. 
  706.     The object class can be used to construct entries in an LDAP directory 
  707.     containing references to other directories or services. This document 
  708.     also defines procedures directory servers should follow when supporting
  709.     these schema elements.                                                 
  710.  
  711.   "Lightweight Directory Access Protocol (v3):  Extension for Transport 
  712.   Layer Security", B. Morgan, J. Hodges, M. Wahl, 09/04/1997, 
  713.   <draft-ietf-asid-ldapv3-tls-02.txt>                                      
  714.  
  715.     This document defines the 'Start Transport Layer Security  (TLS)  
  716.     Operation' for LDAP [LDAPv3, TLS]. This operation provides for TLS 
  717.     establishment in an LDAP association and is defined in terms of an LDAP
  718.     extended request.                                                      
  719.     The key words 'MUST', 'SHOULD', and 'MAY' used in this document are to 
  720.     be interpreted as described in [Bradner97].                            
  721.  
  722.   "Lightweight Directory Access Protocol:  Dynamic Attributes", Tony 
  723.   Genovese, M. Wahl, Y. Yaacovi, 07/03/1997, 
  724.   <draft-ietf-asid-ldap-dynatt-00.txt>                                     
  725.  
  726.     This document defines dynamic attributes and the fashion in which they 
  727.     are being set and used on entries in the directory.  This document 
  728.     builds heavily on the dynamic extensions to LDAP infrastructure as 
  729.     defined in [1].                                                        
  730.     The Lightweight Directory Access Protocol (LDAP) [2] supports 
  731.     lightweight access to static directory services, allowing relatively 
  732.     fast search and update access.  Static directory services store 
  733.     information about people that persists in its accuracy and value over a
  734.     long period of time.                                                   
  735.  
  736.   "The vCard Schema For Use In LDAPv3", F. Dawson, M. O'Brien, 07/08/1997, 
  737.   <draft-ietf-asid-ldapv3schema-vcard-00.txt>                              
  738.  
  739.     The Lightweight Directory Access Protocol (LDAP) [LDAPV3] is gaining 
  740.     widespread acceptance as a method for accessing Internet directories.  
  741.     Many of the LDAP clients accessing these directories also provide 
  742.     support for emitting the directory information in the form of a vCard 
  743.     electronic business card object. This memo defines a new X.500 object 
  744.     class, called the vCardObject, that extends the X.521 standard 
  745.     organizationalPerson and residentialPerson in order to provide a unique
  746.     LDAP schema for accessing  Internet directories in terms of the vCard 
  747.     attributes.                     The schema defined by this memo should 
  748.     be used when accessing a directory via LDAP Version 3 and searching or 
  749.     retrieving directory information based on vCard related attributes. The
  750.     schema describes the attribute types and object classes that have a 
  751.     1-to-one correspondence with vCard properties.  This schema may also be
  752.     used to define a set of object classes and attributes for storing 
  753.     metadata and binding information for a directory entry that closely 
  754.     follows the vCard object in directories that support LDAP.             
  755.  
  756.   "LDAP Replication Requirements", E. Stokes, R. Weiser, 07/24/1997, 
  757.   <draft-ietf-asid-replica-req-00.txt>                                     
  758.  
  759.     This document discusses some of the fundamental requirements for 
  760.     replication and synchronization of the LDAPv3 [LDAPv3] protocol.  It is
  761.     intended to be a gathering place for general replication requirements 
  762.     needed to provide interoperability between informational directories.  
  763.  
  764.   "The Java LDAP Application Program Interface", Tim Howes, Mark Smith, R. 
  765.   Weltman, 09/28/1997, <draft-ietf-asid-ldap-java-api-01.txt>              
  766.  
  767.     This document defines a java language application program interface to
  768.     the lightweight directory access protocol (LDAP), in the form of a 
  769.     class
  770.     library. It complements but does not replace RFC 1823 ([9]), which
  771.     describes a C language application program interface. It updates and
  772.     replaces draft-ietf-asid-ldap-java-api-00.txt [13], in adding 
  773.     clarifica-
  774.     tion on behavior under various circumstances, and in revising support
  775.     for language-sensitive attribute parsing. Other additions and correc-
  776.     tions are listed in the appendix.                                      
  777.  
  778.   "Schema for Replication Information", G. Good, U. Srinivasan, S. Jain, 
  779.   10/08/1997, <draft-ietf-asid-ldap-repl-info-01.txt>                      
  780.  
  781.     This document defines a new attribute syntax and an operational 
  782.     attribute type to store replication agreements within the directory.  
  783.     In addition it defines a framework to detect whether an entry is a 
  784.     master or replica.     The replication agreement structure defined here
  785.     includes a placeholder to specify the replication protocol associated 
  786.     with an agreement.  This document itself does not define any 
  787.     replication protocol. Replication protocols and replication agreements 
  788.     are seen as orthogonal issues.                                         
  789.  
  790.   "LDAP API Extensions for Sort and Simple Paged Results", Chris Weider, 
  791.   Tim Howes, Mark Smith, M. Wahl, A. Herron, 07/30/1997, 
  792.   <draft-ietf-asid-ldapv3-api-ext-00.txt>                                  
  793.  
  794.     This document defines extensions to the LDAP v3 C language API defined
  795.     in [1]. These extensions cover the sort extended control, defined in
  796.     [2],
  797.     and the simple paged results control, defined in [3]. N.B.: while the
  798.     sort extended control can be used on its own, the simple paged results
  799.     control is most useful when used on results that have already been
  800.     sorted.                                                                
  801.  
  802.   "Referral Whois Protocol (RWhois) 2.0", Scott Williamson, M. Mealling, 
  803.   Mark Kosters, J. Singh, Greg Pierce, D. Blacka, K. Zeilstra, 07/30/1997, 
  804.   <draft-ietf-asid-rwhois-00.txt>                                          
  805.  
  806.     This memo describes Version 2.0 of the client/server interaction of 
  807.     RWhois. RWhois provides a distributed system for the display of 
  808.     hierarchical and non-hierarchical information. This system is primarily
  809.     hierarchical by design, allowing for the deterministic reduction of a 
  810.     query and the referral of the user closer to the maintainer of the 
  811.     information. It also identifies the attributes that are 
  812.     non-hierarchical so that they may be indexed into a mesh.              
  813.  
  814.   "The C LDAP Application Program Interface", Chris Weider, Tim Howes, Mark
  815.   Smith, M. Wahl, A. Herron, 07/31/1997, 
  816.   <draft-ietf-asid-ldap-c-api-00.txt>                                      
  817.  
  818.     This document defines a C language application program interface to the
  819.     lightweight directory access protocol (LDAP). This document replaces 
  820.     the
  821.     previous definition of this API, defined in RFC 1823, updating it to
  822.     include support for features found in version 3 of the LDAP protocol.
  823.     New extended operation functions were added to support LDAPv3 features
  824.     such as controls.  In addition, other LDAP API changes were made to
  825.     support information hiding and thread safety.
  826.      
  827.     The C LDAP API is designed to be powerful, yet simple to use. It 
  828.     defines
  829.     compatible synchronous and asynchronous interfaces to LDAP to suit a
  830.     wide variety of applications. This document gives a brief overview of
  831.     the LDAP model, then an overview of how the API is used by an applica-
  832.     tion program to obtain LDAP information.  The API calls are described 
  833.     in
  834.     detail, followed by an appendix that provides some example code demon-
  835.     strating the use of the API. This document provides information to the
  836.     Internet community. It does not specify any standard.
  837.                                                                            
  838.  
  839.   "Java LDAP Controls", R. Weltman, 09/28/1997, 
  840.   <draft-ietf-asid-ldap-java-controls-00.txt>                              
  841.  
  842.     This document defines support for the Preferred Language Control, the
  843.     Server Sorting Control, and the Virtual List Control in the java LDAP
  844.     API.  Controls are an LDAP protocol version 3 extension, to allow pass-
  845.     ing arbitrary control information along with a standard request to a
  846.     server, and to receive arbitrary information back with a standard
  847.     result.                                                                
  848.  
  849. AToM MIB (atommib)
  850. ------------------
  851.  
  852.   "Definitions of Supplemental Managed Objects for ATM Management", Kaj 
  853.   Tesink, A. Smith, E. Spiegel, F. Ly, M. Noto, 08/04/1997, 
  854.   <draft-ietf-atommib-atm2-11.txt>                                         
  855.  
  856.     This memo defines an experimental portion of the Management Information
  857.     Base (MIB) for use with network management protocols in the Internet 
  858.     community.                                                             
  859.  
  860.   "Definitions of Textual Conventions and OBJECT-IDENTITIES for ATM 
  861.   Management", Kaj Tesink, E. Spiegel, M. Noto, 03/06/1997, 
  862.   <draft-ietf-atommib-atm2TC-06.txt>                                       
  863.  
  864.     This memo describes Textual Conventions and OBJECT-IDENTITIES used for 
  865.     managing ATM-based interfaces, devices, networks and services.         
  866.  
  867.   "Definitions of Tests for ATM Management", Kaj Tesink, M. Noto, 
  868.   06/09/1997, <draft-ietf-atommib-test-03.txt>                             
  869.  
  870.     This memo defines an experimental portion of the Management Information
  871.     Base (MIB) for use with network management protocols in the Internet 
  872.     community.  In particular, it describes objects used for managing 
  873.     ATM-based interfaces, devices, networks and services in addition to 
  874.     those defined in the ATM MIB [1], to provide additional support for the
  875.     management of ATM Loopback Tests.                                      
  876.  
  877.   "Managed Objects for Controlling the Collection and Storage of Accounting
  878.   Information for Connection-Oriented Networks", Keith McCloghrie, Juha 
  879.   Heinanen, A. Prasad, W. Greene, 06/10/1997, 
  880.   <draft-ietf-atommib-acct-04.txt>                                         
  881.  
  882.     This memo defines an experimental portion of the Management Information
  883.     Base (MIB) for use with network management protocols in the Internet 
  884.     community.  In particular, it describes managed objects used for 
  885.     controlling the collection and storage of accounting information for 
  886.     connection-oriented networks such as ATM.  The accounting data is 
  887.     collected into files for later retrieval via a file transfer protocol. 
  888.     For information on data which can be collected for ATM networks, see 
  889.     [9].                                                                   
  890.  
  891.   "Definitions of Managed Objects for ATM Management", Kaj Tesink, 
  892.   02/12/1997, <draft-ietf-atommib-atm1ng-03.txt>                           
  893.  
  894.     This memo defines an experimental portion of the Management Information
  895.     Base (MIB) for use with network management protocols in the Internet 
  896.     community.  In particular, it describes objects used for managing 
  897.     ATM-based interfaces, devices, networks and services.                  
  898.     This memo specifies a MIB module in a manner that is both compliant to 
  899.     the SNMPv2 SMI, and semantically identical to the peer SNMPv1 
  900.     definitions.     This memo does not specify a standard for the Internet
  901.     community.                                                             
  902.  
  903.   "Textual Conventions for MIB Modules Using Performance History Based on 
  904.   15 Minute Intervals", Kaj Tesink, 05/12/1997, 
  905.   <draft-ietf-atommib-perfhistTC-01.txt>                                   
  906.  
  907.     When designing a MIB module, it is often useful to define new types 
  908.     similar to those defined in the SMI.  In comparison to a type defined 
  909.     in the SMI, each of these new types has a different name, a similar 
  910.     syntax, but a more precise semantics.  These newly defined types are 
  911.     termed textual conventions, and are used for the convenience of humans 
  912.     reading the MIB module.  This is done through Textual Conventions as 
  913.     defined in RFC1903[1].  It is the purpose of this document to define 
  914.     the set of textual conventions to be used when performance history 
  915.     based on 15 minute intervals is kept. See for example the Trunk MIB 
  916.     modules [3][4][5].        This memo does not specify a standard for the
  917.     Internet community.                                                    
  918.  
  919.   "Definitions of Managed Objects for the SONET/SDH Interface Type", Tracy 
  920.   Brown, Kaj Tesink, 07/07/1997, <draft-ietf-atommib-sonetng-02.txt>       
  921.  
  922.     This memo defines an experimental portion of the Management Information
  923.     Base (MIB) for use with network management protocols in TCP/IP-based 
  924.     internets.  In particular, it defines objects for managing Synchronous 
  925.     Optical Network/Synchronous Digital Hierarchy (SONET/SDH) objects.  
  926.     This document is a companion document with Definitions of Managed 
  927.     Objects for the DS1/E1 and DS3/E3 Interface Types, RFC1406 [14] and 
  928.     RFC1407 [13].      This memo specifies a MIB module in a manner that is
  929.     both compliant to the SNMPv2 SMI, and semantically identical to the 
  930.     peer SNMPv1 definitions.                                               
  931.  
  932.   "Accounting Information for ATM Networks", Keith McCloghrie, Juha 
  933.   Heinanen, A. Prasad, W. Greene, 06/06/1997, 
  934.   <draft-ietf-atommib-atmacct-01.txt>                                      
  935.  
  936.     This memo defines an experimental portion of the Management Information
  937.     Base (MIB) for use with network management protocols in the Internet 
  938.     community.  A separate memo [8] defines managed objects, in a manner 
  939.     independent of the type of network, for controlling the selection, 
  940.     collection and storage of accounting information into files for later 
  941.     retrieval via a file transfer protocol. This memo defines a set of 
  942.     ATM-specific accounting information which can be collected for 
  943.     connections on ATM networks.                                           
  944.  
  945.   "Managed Objects for Recording ATM Performance History Data Based on 15 
  946.   Minute Intervals", G. Mouradian, 06/10/1997, 
  947.   <draft-ietf-atommib-atmhist-00.txt>                                      
  948.  
  949.     This memo defines an experimental portion of the Management Information
  950.     Base (MIB) for use with network management protocols in the Internet 
  951.     community.  In particular, it describes managed objects to record and 
  952.     retrieve ATM performance history data recorded in 15 minute interval.  
  953.     The functionality defined in this document is intended to satisfy the 
  954.     requirements defined by the ATM Forum in [9].                          
  955.  
  956. Audio/Video Transport (avt)
  957. ---------------------------
  958.  
  959.   "RTP usage with Layered Multimedia Streams", M. Speer, S. McCanne, 
  960.   06/24/1997, <draft-speer-avt-layered-video-02.txt>                       
  961.  
  962.     This draft describes how one should make use of RTP (rfc1889) when 
  963.     employing layered media streams.  This document is meant for 
  964.     implementors of internet multimedia applications that want to use RTP 
  965.     and layered media streams.                                             
  966.  
  967.   "RTP Payload Format for H.263 Video Streams", C. Zhu, 09/11/1997, 
  968.   <draft-ietf-avt-rtp-payload-04.txt>                                      
  969.  
  970.     This document specifies the payload format for encapsulating an H.263
  971.     bitstream in the Real-Time Transport Protocol (RTP). Three modes are
  972.     defined for the H.263 payload header. An RTP packet can use one of the
  973.     three modes for H.263 video streams depending on the desired
  974.     network packet size and H.263 encoding options employed.
  975.     The shortest H.263 payload header (mode A) supports fragmentation
  976.     at Group of Block (GOB) boundaries. The long H.263 payload headers
  977.     (mode B and C) support fragmentation at Macroblock (MB) boundaries.    
  978.  
  979.   "RTP Payload Format for Bundled MPEG", R. Civanlar, G. Cash, B. Haskell, 
  980.   02/27/1997, <draft-civanlar-bmpeg-01.txt>                                
  981.  
  982.     This document describes a payload type for bundled, MPEG-2 encoded 
  983.     video and audio data to be used with RTP, version 2. Bundling has some 
  984.     advantages for this payload type particularly when it is used for 
  985.     video-on-demand applications. This payload type is to be used when its 
  986.     advantages are important enough to sacrifice the modularity of having 
  987.     separate audio and video streams.                                      
  988.     A technique to improve packet loss resilience based on 'out-of-band' 
  989.     transmission of MPEG-2 specific, vital information is described also.  
  990.  
  991.   "Alternatives for Enhancing RTCP Scalability", B. Aboba, 01/29/1997, 
  992.   <draft-aboba-rtpscale-02.txt>                                            
  993.  
  994.     This document discusses current issues with RTCP scalability as well as
  995.     describing the advantages and disadvantages of possible solutions.     
  996.  
  997.   "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", V. Jacobson,
  998.   Stephen Casner, 07/14/1997, <draft-ietf-avt-crtp-03.txt>                 
  999.  
  1000.     This document describes a method for compressing the headers of 
  1001.     IP/UDP/RTP datagrams to reduce overhead on low-speed serial links. In 
  1002.     many cases, all three headers can be compressed to 2-4 bytes.          
  1003.     Comments are solicited and should be addressed to the working group 
  1004.     mailing list rem-conf@es.net and/or the author(s).                     
  1005.  
  1006.   "Real-Time Transport Protocol Management Information Base", S. Naudus, M.
  1007.   Baugher, J. Du, 03/26/1997, <draft-ietf-avt-rtp-mib-00.txt>              
  1008.  
  1009.     This memo defines an experimental  Management Information Base (MIB) 
  1010.     for use with network management protocols in TCP/IP-based internets.  
  1011.     In particular, it defines objects for managing Real-Time Transport 
  1012.     Protocol Systems [1].  Comments should be made to the IETF Audio/Video 
  1013.     Transport Working Group.                                               
  1014.     This memo does not specify a standard for the Internet community.      
  1015.  
  1016.   "RTP Profile for Audio and Video Conferences with Minimal Control", H. 
  1017.   Schulzrinne, 07/31/1997, <draft-ietf-avt-profile-new-01.txt,.ps>         
  1018.  
  1019.     This memo describes a profile called 'RTP/AVP' for the
  1020.              use of the real-time transport protocol (RTP), version 2,
  1021.              and the associated control protocol, RTCP, within audio
  1022.              and video multiparticipant conferences with minimal
  1023.              control. It provides interpretations of generic fields
  1024.              within the RTP specification suitable for audio and video
  1025.              conferences. In particular, this document defines a set
  1026.              of default mappings from payload type numbers to
  1027.              encodings.
  1028.     
  1029.              The document also describes how audio and video data may
  1030.              be carried within RTP. It defines a set of standard
  1031.              encodings and their names when used within RTP. However,
  1032.              the encoding definitions are independent of the
  1033.              particular transport mechanism used. The descriptions
  1034.              provide pointers to reference implementations and the
  1035.              detailed standards. This document is meant as an aid for
  1036.              implementors of audio, video and other real-time
  1037.              multimedia applications.                                      
  1038.  
  1039.   "RTP Payload Format for MPEG1/MPEG2 Video", D. Hoffman, G. Fernando, V. 
  1040.   Goyal, R. Civanlar, 06/27/1997, <draft-ietf-avt-mpeg-new-01.txt>         
  1041.  
  1042.     This memo describes a packetization scheme for MPEG video and audio 
  1043.     streams.  The scheme proposed can be used to transport such a video or 
  1044.     audio flow over the transport protocols supported by RTP.  Two 
  1045.     approaches are described. The first is designed to support maximum 
  1046.     interoperability with MPEG System environments.  The second is designed
  1047.     to provide maximum compatibility with other RTP-encapsulated media 
  1048.     streams and future conference control work of the IETF.                
  1049.     This memo is a revision of RFC 2038, an Internet standards track 
  1050.     protocol, prepared for publication as a revised RFC.  In this revision,
  1051.     the packet loss resilience mechanisms in Section 3.4 were extended to 
  1052.     include additional picture header information required for MPEG2.      
  1053.  
  1054.   "RTP Payload Format for QuickTime Media Streams", D. Singer, 07/23/1997, 
  1055.   <draft-ietf-avt-qt-rtp-00.txt>                                           
  1056.  
  1057.     This document specifies the payload format for encapsulating QuickTime 
  1058.     media streams in the Realtime Transport Protocol (RTP).  This 
  1059.     specification is intended for QuickTime media/codec types that are not 
  1060.     already handled by other RTP payload specifications. Each QuickTime 
  1061.     media track within a movie is sent over a separate RTP session and 
  1062.     synchronized using standard RTP techniques.  A static QuickTime payload
  1063.     type (if assigned) or a dynamic payload type may be used. A QuickTime 
  1064.     header within the RTP payload is defined to carry the media type and 
  1065.     other media specific information. A packetization scheme is defined for
  1066.     the media data. This specification is intended for streaming stored 
  1067.     QuickTime movies as well as live QuickTime content.                    
  1068.  
  1069.   "RTP Payload for DTMF Digits", H. Schulzrinne, 07/31/1997, 
  1070.   <draft-ietf-avt-dtmf-00.txt,.ps>                                         
  1071.  
  1072.     This memo describes how to carry dual-tone multifrequency
  1073.              (DTMF) signaling in RTP packets.                              
  1074.  
  1075.   "An A/V Profile Extension for Generic Forward Error Correction in RTP", 
  1076.   J. Rosenberg, H. Schulzrinne, 08/04/1997, <draft-ietf-avt-fec-00.txt>    
  1077.  
  1078.     This document specifies an extension to RFC 1890 which allows for
  1079.        forward correction (FEC) of continuous media encapsulated in RTP. 
  1080.     The
  1081.        profile is engineered for FEC algorithms based on the exclusive or
  1082.        (parity) operation, although it can be used with other techniques.
  1083.        The profile extension allows end systems to transmit using arbitrary
  1084.        block lengths and parity schemes. It also allows for the recovery of
  1085.        both the payload and critical RTP header fields. It is backwards 
  1086.     com-
  1087.        patible with existing RFC 1890 implementations, so that receivers
  1088.        which do not wish to implement FEC can just ignore the extensions.  
  1089.  
  1090.   "Options for Repair of Streaming Media", O Hodson, 08/21/1997, 
  1091.   <draft-ietf-avt-info-repair-00.txt>                                      
  1092.  
  1093.         This document summarizes a range of possible techniques
  1094.         for the repair of continuous media streams subject to packet
  1095.         loss.  The techniques discussed include redundant transmission,
  1096.         retransmission, interleaving and forward error correction.
  1097.         The range of applicability of these techniques is noted,
  1098.         together with the protocol requirements and dependencies.
  1099.      
  1100.                                                                            
  1101.  
  1102. Benchmarking Methodology (bmwg)
  1103. -------------------------------
  1104.  
  1105.   "Benchmarking Terminology for LAN Switching Devices", B. Mandeville, 
  1106.   09/18/1997, <draft-ietf-bmwg-lanswitch-07.txt>                           
  1107.  
  1108.        This document is intended to provide terminology
  1109.        for the benchmarking of local area network (LAN) switching devices.
  1110.        It extends the terminology already defined for benchmarking network
  1111.        interconnect devices in RFCs 1242 and 1944 to switching devices.    
  1112.     Although it might be found useful to apply some of the terms defined
  1113.        here to a broader range of network interconnect devices, this RFC
  1114.        primarily deals with devices which switch frames at the Medium
  1115.        Access Control (MAC) layer.  It defines terms in relation to the
  1116.        traffic put to use when benchmarking switching devices, forwarding
  1117.        performance, congestion control, latency, address handling and
  1118.        filtering.                                                          
  1119.  
  1120.   "Terminology for Cell/Call Benchmarking", R. Craig, 03/25/1997, 
  1121.   <draft-ietf-bmwg-call-01.txt>                                            
  1122.  
  1123.     The purpose of this draft is to add terminology specific to the cell 
  1124.     and call-based switch environment to that defined by the Benchmarking 
  1125.     Methodology Working Group (BMWG) of the Internet Engineering Task Force
  1126.     (IETF) in RFC1242.                                                     
  1127.     While primarily directed towards wide area switches, portions of the 
  1128.     document may be useful for benchmarking other devices such as ADSU's.  
  1129.  
  1130.   "A One-way Delay Metric for IPPM", Guy Almes, S. Kalidindi, 08/04/1997, 
  1131.   <draft-ietf-bmwg-ippm-delay-02.txt>                                      
  1132.  
  1133.     This memo defines a metric for one-way delay of packets across Inter-
  1134.        net paths.  It builds on notions introduced and discussed in the 
  1135.     IPPM
  1136.        Framework document (currently 'Framework  for  IP  Provider  
  1137.     Metrics'
  1138.        <draft-ietf-bmwg-ippm-framework-01.txt>); the reader is assumed to 
  1139.     be
  1140.        familiar with that document.
  1141.     
  1142.        This memo is intended to be very parallel in structure to a 
  1143.     companion
  1144.        document  for  Packet  Loss  ('A Packet Loss Metric for IPPM' 
  1145.     <draft-
  1146.        ietf-bmwg-ippm-loss-01.txt>).
  1147.     
  1148.      +    A 'singleton' analytic metric, called  Type-P-One-way-Delay,  
  1149.     will
  1150.           be introduced to measure a single observation of one-way delay.
  1151.      +    Using  this  singleton  metric, a 'sample', called 
  1152.     Type-P-One-way-
  1153.           Delay-Stream, will be introduced to measure a sequence of  
  1154.     single-
  1155.           ton delays measured at times taken from a Poisson process.
  1156.      +    Using  this  sample,  several  'statistics'  of the sample will 
  1157.     be
  1158.           defined and discussed.
  1159.     
  1160.        This progression from singleton to sample to statistics,  with  
  1161.     clear
  1162.        separation among them, is important.
  1163.      
  1164.        Whenever  a  technical term from the IPPM Framework document is 
  1165.     first
  1166.        used in this memo, it will be tagged with  a  trailing  asterisk,  
  1167.     as
  1168.        with >>term*<<.                                                     
  1169.  
  1170.   "Empirical Bulk Transfer Capacity", Matt Mathis, 08/04/1997, 
  1171.   <draft-ietf-bmwg-ippm-treno-btc-01.txt>                                  
  1172.  
  1173.     Bulk Transport Capacity (BTC) is a measure of a network's ability to 
  1174.     transfer significant quantities of data with a single congestion-aware 
  1175.     transport connection (e.g. state-of-the-art TCP).  For many 
  1176.     applications the BTC of the underlying network dominates the the 
  1177.     overall elapsed time for the application, and thus dominates the 
  1178.     performance as perceived by a user.                                    
  1179.     The BTC is a property of an IP cloud (links, routers, switches, etc) 
  1180.     between a pair of hosts.  It does not include the hosts themselves (or 
  1181.     their transport-layer software).  However, congestion control is 
  1182.     crucial to the BTC metric because the Internet depends on the end 
  1183.     systems to fairly divide the available bandwidth on the basis of common
  1184.     congestion behavior. The BTC metric is based on the performance of a 
  1185.     reference congestion control algorithm that has particularly uniform 
  1186.     and stable behavior.                                                   
  1187.  
  1188.   "Framework for IP Provider Metrics", Guy Almes, J. Mahdavi, Vern Paxson, 
  1189.   08/01/1997, <draft-ietf-bmwg-ippm-framework-01.txt>                      
  1190.  
  1191.        The purpose of this memo is to define a general framework for 
  1192.     partic-
  1193.        ular  metrics  to  be  developed by the IETF's IP Performance 
  1194.     Metrics
  1195.        effort, begun by the Benchmarking Methodology Working Group (BMWG) 
  1196.     of
  1197.        the Operational Requirements Area, and being continued by the IP 
  1198.     Per-
  1199.        formance Metrics Working Group (IPPM) of the Transport Area.        
  1200.  
  1201.   "Terminology for IP Multicast Benchmarking", Kevin Dubray, 08/02/1997, 
  1202.   <draft-ietf-bmwg-mcast-02.txt>                                           
  1203.  
  1204.     The purpose of this draft is to add terminology specific to the 
  1205.     benchmarking of multicast IP forwarding devices. It builds upon the 
  1206.     tenets set forth in RFC 1242, RFC 1944, and other IETF Benchmarking 
  1207.     Methodology Working Group (BMWG) effort and extends them to the 
  1208.     multicast paradigm.                                                    
  1209.  
  1210.   "A Packet Loss Metric for IPPM", Guy Almes, S. Kalidindi, 08/04/1997, 
  1211.   <draft-ietf-bmwg-ippm-loss-01.txt>                                       
  1212.  
  1213.     This memo defines a metric for packet loss across Internet paths.  It 
  1214.     builds on notions introduced and discussed in the IPPM Framework 
  1215.     document (currently 'Framework for  IP  Provider  Metrics'  
  1216.     <draft-ietf-bmwg-ippm-framework-00.txt>);  the  reader  is assumed to 
  1217.     be familiar with that document.                                        
  1218.     This memo is intended to be very parallel in structure to a companion 
  1219.     document  for  One-way  Delay  (currently 'A One-way Delay Metric for 
  1220.     IPPM' <draft-ietf-bmwg-ippm-delay-00.txt>); the reader is assumed  to 
  1221.     be familiar with that document.                                        
  1222.  
  1223.   "Benchmarking Terminology for Network Security Devices", David Newman, 
  1224.   07/30/1997, <draft-ietf-bmwg-secperf-00.txt>                             
  1225.  
  1226.     This document defines terms used in measuring the performance of
  1227.     network security devices. It extends the terminology already used
  1228.     for benchmarking routers and switches to network security devices.
  1229.     The primary metrics defined in this document are maximum
  1230.     forwarding rate and maximum number of connections.
  1231.     
  1232.                                                                            
  1233.  
  1234. Calendaring and Scheduling (calsch)
  1235. -----------------------------------
  1236.  
  1237.   "Internet Calendaring and Scheduling Core Object Specification 
  1238.   (iCalendar)", F. Dawson, D. Stenerson, 10/31/1997, 
  1239.   <draft-ietf-calsch-ical-04.txt>                                          
  1240.  
  1241.        There is a clear need to provide and deploy interoperable 
  1242.     calendaring
  1243.        and scheduling services for the Internet. Current group scheduling
  1244.        and Personal Information Management (PIM) products are being 
  1245.     extended
  1246.        for use across the Internet, today, in proprietary ways. This memo
  1247.        has been defined to provide the a definition of a common format for
  1248.        openly exchanging calendaring and scheduling information across the
  1249.        Internet.
  1250.      
  1251.        This memo is formatted as a registration for a MIME media type per
  1252.        [RFC 2048]. However, the format in this memo is equally applicable
  1253.        for use outside of a MIME message content type.
  1254.      
  1255.        The proposed media type value is ''TEXT/CALENDAR''. This string 
  1256.     would
  1257.        label a media type containing calendaring and scheduling information
  1258.        encoded as text characters formatted in a manner outlined below.
  1259.      
  1260.        This MIME media type provides a standard content type for capturing
  1261.        calendar event and to-do information. It also can be used to convey
  1262.        free/busy time information. The content type is suitable as a MIME
  1263.        message entity that can be transferred over MIME based email systems
  1264.        or using HTTP. In addition, the content type is useful as an object 
  1265.     for interactions between desktop applications using the operating
  1266.        system clipboard, drag/drop or file systems capabilities.
  1267.      
  1268.        This memo is based on the earlier work of the vCalendar 
  1269.     specification
  1270.        for the exchange of personal calendaring and scheduling information.
  1271.        In order to avoid confusion with this referenced work, this memo is
  1272.        to be known as the iCalendar specification. This memo is based on 
  1273.     the
  1274.        calendaring and scheduling model defined in []. The document is also
  1275.        the basis for the calendaring and scheduling interoperability
  1276.        protocol defined in [ITIP].
  1277.      
  1278.        This memo also includes the format for defining iCalendar object
  1279.        methods. An iCalendar object method is a set of usage constraints 
  1280.     for
  1281.        the iCalendar object. For                                           
  1282.  
  1283.   "Core Object Specification - Issues Document", F. Dawson, Anik Ganguly, 
  1284.   D. Stenerson, 04/29/1997, <draft-ietf-calsch-ical-issues-01.txt>         
  1285.  
  1286.     This document is an IETF CALSCH working group document. The document is
  1287.     used as a tool for recording issues and their resolution with mailing 
  1288.     list discussions.                                                      
  1289.     This Issues Document is intended to track the resolution of issues 
  1290.     related to the 'Core Object Specification' deliverable.                
  1291.     The most current version of this document can be found on the IETF 
  1292.     CALSCH Working Group document archive at http://www.imc.org.           
  1293.     Issues within this document are classified as either being OPEN or 
  1294.     RESOLVED. Additionally, an issue may be found to no longer be a concern
  1295.     and may be classified as WITHDRAWN. Issues falling into each of these 
  1296.     categories are listed in a separate section.                           
  1297.     An issue is documented with a short summary title, a brief description,
  1298.     and a list of identified alternatives. A resolved issue will also 
  1299.     include a description of the resolution and the date/venue that the 
  1300.     resolution was reached.                                                
  1301.     Distribution of this document is unlimited.                            
  1302.  
  1303.   "Calendaring Interoperability over HTTP (CIH)", S. Hanna, 02/10/1997, 
  1304.   <draft-ietf-calsch-cih-00.txt>                                           
  1305.  
  1306.     Calendaring Interoperability over HTTP (CIH) is a technique for 
  1307.     exchanging calendaring information between scheduling systems using the
  1308.     Hypertext Transfer Protocol (HTTP). This allows users to schedule 
  1309.     meetings with anyone else, no matter what scheduling software they use.
  1310.     This document is a tentative exploration of whether CIH is feasible and
  1311.     what the pros and cons are relative to a brand new protocol like the 
  1312.     Calendaring Interoperability Protocol (CIP). The primary benefit of CIH
  1313.     over CIP and motivation for this project is that we avoid implementing 
  1314.     a whole new protocol, such as writing and debugging the protocol, 
  1315.     convincing vendors to write new code to support it, and then convincing
  1316.     users to deploy it.                                                    
  1317.  
  1318.   "Real-time Protocol Requirements", Anik Ganguly, 03/28/1997, 
  1319.   <draft-ietf-calsch-rtreq-00.txt>                                         
  1320.  
  1321.     The purpose of this document is to create a framework for selecting the
  1322.     appropriate solution for a real-time protocol designed to allow 
  1323.     calendaring and scheduling systems from different vendors to 
  1324.     interoperate.  To that end, it describes the assumptions about the 
  1325.     context in which this protocol will operate, and the requirements that 
  1326.     the protocol must meet.   These requirements are not intended to apply 
  1327.     to a companion protocol which will use E-mail based transport to 
  1328.     achieve interoperability.  The E-mail based protocol, which is the 
  1329.     subject of a different document, will not make any assumptions about 
  1330.     transport latency.                                                     
  1331.  
  1332.   "iCalendar Message-based Interoperability Protocol (iMIP)", F. Dawson, S.
  1333.   Mansour, S. Silverberg, 10/27/1997, <draft-ietf-calsch-imip-02.txt>      
  1334.  
  1335.        This document specifies a binding from the iCalendar Transport-
  1336.        independent Interoperability Protocol [ITIP] to Internet email-based
  1337.        transports. Calendaring entries defined by the iCalendar Object 
  1338.     Model
  1339.        [ICAL] are composed using constructs from [RFC-822], [RFC-2045],
  1340.        [RFC-2046], [RFC-2047], [RFC-2048] and [RFC-2049].
  1341.      
  1342.        This document is based on the calendaring and scheduling model
  1343.        defined by [ICMS].
  1344.      
  1345.        This document is based on discussions within the Internet 
  1346.     Engineering
  1347.        Task Force (IETF) Calendaring and Scheduling (CALSCH) working group.
  1348.        More information about the IETF CALSCH working group activities can
  1349.        be found on the IMC website at http://www.imc.org, the IETF website
  1350.        at http://www.ietf.org/html.charters/calsch-charter.html. Refer to
  1351.        the references within this document for further information on how 
  1352.     to
  1353.        access these various documents.
  1354.      
  1355.        Distribution of this document is unlimited. Comments and suggestions
  1356.        for improvement should be sent to the authors.                      
  1357.  
  1358.   "Internet Calendar Model Specification", John Noerenberg, 10/27/1997, 
  1359.   <draft-ietf-calsch-mod-02.txt>                                           
  1360.  
  1361.     Internet Calendaring and Scheduling protocols require the definition of
  1362.     objects to encapsulate an event to be scheduled, a calendar on which
  1363.     the event will be stored, and means for exchanging these objects across
  1364.     the Internet between calendars on behalf of people for whom the
  1365.     calendars are meaningful.  This document gives an abstract model of the
  1366.     objects and the protocols necessary to accomplish this kind of
  1367.     information exchange.  It will establish the context in which other
  1368.     Calendaring and Scheduling RFCs can be interpreted.  Included are brief
  1369.     introductions to the other components of Internet calendar protocols
  1370.     and definitions of nomenclature common to all documents defining these
  1371.     protocols.  Reading this document will enable implementors and users of
  1372.     Internet Calendaring and Scheduling protocols to understand the goals
  1373.     and constraints chosen for related protocols.                          
  1374.  
  1375.   "iCalendar Transport-Independent Interoperability Protocol (iTIP) 
  1376.   Scheduling Events, BusyTime, To-dos and Journal Entries", R. Hopson, S. 
  1377.   Mansour, Frank Dawson  Jr., S. Silverberg, 10/28/1997, 
  1378.   <draft-ietf-calsch-itip-01.txt>                                          
  1379.  
  1380.     This document specifies how calendaring systems use iCalendar objects
  1381.        to interoperate with other calendar systems. It does so in a general
  1382.        way so as to allow multiple methods of communication between 
  1383.     systems.
  1384.        Subsequent documents specify interoperable methods of communications
  1385.        between systems that use this protocol.
  1386.      
  1387.        The document outlines a model for calendar exchange that defines 
  1388.     both
  1389.        static and dynamic event, to-do, journal and free/busy objects.
  1390.        Static objects are used to transmit information from one entity to
  1391.        another without the expectation of continuity or referential
  1392.        integrity with the original item. Dynamic objects are a superset of
  1393.        static objects and will gracefully degrade to their static
  1394.        counterparts for clients that only support static objects.          
  1395.  
  1396. Common Authentication Technology (cat)
  1397. --------------------------------------
  1398.  
  1399.   "Independent Data Unit Protection Generic Security Service Application 
  1400.   Program Interface  (IDUP-GSS-API)", C. Adams, 10/14/1997, 
  1401.   <draft-ietf-cat-idup-gss-08.txt>                                         
  1402.  
  1403.        The IDUP-GSS-API extends the GSS-API [RFC-2078] for applications
  1404.        requiring protection of a generic data unit (such as a file or
  1405.        message) in a way which is independent of the protection of any 
  1406.     other
  1407.        data unit and independent of any concurrent contact with designated
  1408.        'receivers' of the data unit.  Thus, it is suitable for applications
  1409.        such as secure electronic mail where data needs to be protected
  1410.        without any on-line connection with the intended recipient(s) of 
  1411.     that
  1412.        data.  The protection offered by IDUP includes services such as data
  1413.        origin authentication with data integrity, data confidentiality with
  1414.        data integrity, and support for non-repudiation services.  
  1415.     Subsequent
  1416.        to being protected, the data unit can be transferred to the
  1417.        recipient(s) - or to an archive - perhaps to be processed
  1418.        ('unprotected') only days or years later.
  1419.      
  1420.        Throughout the remainder of this document, the 'unit' of data
  1421.        described in the above paragraph will be referred to as an IDU
  1422.        (Independent Data Unit).  The IDU can be of any size (the 
  1423.     application
  1424.        may, if it wishes, split the IDU into pieces and have the protection
  1425.        computed a piece at a time, but the resulting protection token
  1426.        applies to the entire IDU).  However, the primary characteristic of
  1427.        an IDU is that it represents a stand-alone unit of data whose
  1428.        protection is entirely independent of any other unit of data.  If an
  1429.        application protects several IDUs and sends them all to a single    
  1430.     receiver, the IDUs may be unprotected by that receiver in any order
  1431.        over any time span; no logical connection of any kind is implied by
  1432.        the protection process itself.
  1433.      
  1434.        As with RFC-2078, this IDUP-GSS-API definition provides security
  1435.        services to callers in a generic fashion, supportable with a range 
  1436.     of
  1437.        underlying mechanisms and technologies and hence allowing source-
  1438.        level portability of applications to different environments. This
  1439.        specification                                                       
  1440.  
  1441.   "Public Key Cryptography for Initial Authentication in Kerberos", 
  1442.   Clifford Neuman, John Wray, B. Tung, J. Trostle, A. Medvinsky, 
  1443.   08/01/1997, <draft-ietf-cat-kerberos-pk-init-04.txt>                     
  1444.  
  1445.         This document defines extensions (PKINIT) to the Kerberos protocol
  1446.         specification (RFC 1510 [1]) to provide a method for using public
  1447.         key cryptography during initial authentication.  The methods
  1448.         defined specify the ways in which preauthentication data fields and
  1449.         error data fields in Kerberos messages are to be used to transport
  1450.         public key data.
  1451.                                                                            
  1452.  
  1453.   "Generic Security Service API Version 2 : C-bindings", John Wray, 
  1454.   03/20/1997, <draft-ietf-cat-gssv2-cbind-04.txt>                          
  1455.  
  1456.     This draft document specifies C language bindings for Version 2 of the 
  1457.     Generic Security Service Application Program Interface (GSSAPI), which 
  1458.     is described at a language-independent conceptual level in other drafts
  1459.     [GSSAPI]. It revises RFC-1509, making specific incremental changes in 
  1460.     response to implementation experience and liaison requests.  It is 
  1461.     intended, therefore, that this draft or a successor version thereof 
  1462.     will become the basis for subsequent progression of the GSS-API 
  1463.     specification on the standards track.                                  
  1464.     The Generic Security Service Application Programming Interface provides
  1465.     security services to its callers, and is intended for implementation 
  1466.     atop a variety of underlying cryptographic mechanisms.  Typically, 
  1467.     GSSAPI callers will be application protocols into which security 
  1468.     enhancements are integrated through invocation of services provided by 
  1469.     the GSSAPI. The GSSAPI allows a caller application to authenticate a 
  1470.     principal identity associated with a peer application, to delegate 
  1471.     rights to a peer, and to apply security services such as 
  1472.     confidentiality and integrity on a per-message basis.                  
  1473.  
  1474.   "Independent Data Unit Protection Generic Security Service Application 
  1475.   Program Interface: C-bindings", D. Thakkar, S. Klump, 04/16/1997, 
  1476.   <draft-ietf-cat-idup-cbind-03.txt>                                       
  1477.  
  1478.     The Independent Data Unit Protection Generic Security Service 
  1479.     Application Program Interface (IDUP-GSS-API) extends the GSS-API 
  1480.     [RFC-1508] for applications requiring protection of a generic data unit
  1481.     (such as a file or message) in a way that is independent of the 
  1482.     protection of any other data unit and independent of any concurrent 
  1483.     contact with designated 'receivers' of the data unit.  Thus, it is 
  1484.     suitable for applications such as secure electronic mail where data 
  1485.     needs to be protected without any on-line connection with the intended 
  1486.     recipient(s) of that data.  The protection offered by the IDUP includes
  1487.     data origin authentication with data integrity, data confidentiality 
  1488.     with data integrity, and support for non-repudiation services.  
  1489.     Subsequent to being protected, the independent data unit can be 
  1490.     transferred to the recipient(s) - or to an archive - perhaps to be 
  1491.     processed ('unprotected') only days or years later.          The 
  1492.     Independent Data Unit Protection Generic Security Service Application 
  1493.     Program Interface for Signing and Encrypting (IDUP-SE) provides a 
  1494.     simplified API for the services of signing and encrypting.             
  1495.  
  1496.   "The Simple and Protected GSS-API Negotiation Mechanism", D. Pinkas, E. 
  1497.   Baize, 07/22/1997, <draft-ietf-cat-snego-06.txt>                         
  1498.  
  1499.     This draft document specifies a Security Negotiation Mechanism for the 
  1500.     Generic Security Service Application Program Interface (GSS-API) which 
  1501.     is described in [1].         The GSS-API provides a generic interface 
  1502.     which can be layered atop different security mechanisms such that if 
  1503.     communicating peers acquire GSS-API credentials for the same security 
  1504.     mechanism, then a security context may be established between them 
  1505.     (subject to policy). However, GSS-API doesn't prescribe the method by 
  1506.     which GSS-API peers can establish whether they have a common security 
  1507.     mechanism.        The Simple and Protected GSS-API Negotiation 
  1508.     Mechanism defined here is a pseudo-security mechanism, represented by 
  1509.     the object identifier iso.org.dod.internet.security.mechanism.snego 
  1510.     (1.3.6.1.5.5.2) which enables GSS-API peers to determine in-band 
  1511.     whether their credentials share common GSS-API security mechanism(s), 
  1512.     and if so, to invoke normal security context establishment for a 
  1513.     selected common security mechanism. This is most useful for 
  1514.     applications that are based on GSS-API implementations which support 
  1515.     multiple security mechanisms.                                          
  1516.  
  1517.   "Extended Generic Security Service APIs: XGSS-APIs Access control and 
  1518.   delegation extensions", D. Pinkas, T. Parker, 03/24/1997, 
  1519.   <draft-ietf-cat-xgssapi-acc-cntrl-02.txt>                                
  1520.  
  1521.     The Generic Security Service Application Program Interface (GSS-API), 
  1522.     as defined in RFC-1508, provides security services to callers in a 
  1523.     generic fashion, supportable with a range of underlying mechanisms and 
  1524.     technologies and hence allowing source-level portability of 
  1525.     applications to different environments. It defines GSS-API services and
  1526.     primitives at a level independent of underlying mechanism and 
  1527.     programming language environment.     The GSSAPI allows a caller 
  1528.     application to authenticate a principal identity associated with a peer
  1529.     application, to delegate rights to a peer, and to apply security 
  1530.     services such as confidentiality and integrity on a per-message basis. 
  1531.     The primitives of the GSS-API do not currently allow support of 
  1532.     security attributes other than a single identity and do not allow fine 
  1533.     control of delegation.                                                 
  1534.  
  1535.   "Public Key Cryptography for Cross-Realm Authentication in Kerberos", G. 
  1536.   Tsudik, Clifford Neuman, B. Sommerfeld, B. Tung, M. Hur, T. Ryutov, A. 
  1537.   Medvinsky, 08/01/1997, <draft-ietf-cat-kerberos-pk-cross-02.txt>         
  1538.  
  1539.     This document defines extensions to the Kerberos protocol
  1540.         specification (RFC 1510, 'The Kerberos Network Authentication
  1541.         Service (V5)', September 1993) to provide a method for using
  1542.         public key cryptography during cross-realm authentication.  The
  1543.         methods defined here specify the way in which message exchanges
  1544.         are to be used to transport cross-realm secret keys protected by
  1545.         encryption under public keys certified as belonging to KDCs.       
  1546.  
  1547.   "Public Key Utilizing Tickets for Application Servers (PKTAPP)", Clifford
  1548.   Neuman, M. Hur, A. Medvinsky, 02/17/1997, <draft-ietf-cat-pktapp-00.txt> 
  1549.  
  1550.     Public key based Kerberos for Distributed Authentication[1], (PKDA) 
  1551.     proposed by Sirbu & Chuang, describes PK based authentication that 
  1552.     eliminates the use of a centralized key distribution center while 
  1553.     retaining the advantages of Kerberos tickets.  This draft describes 
  1554.     how, without any modification, the PKINIT specification[2] may be used 
  1555.     to implement the ideas introduced in PKDA.  The benefit is that only a 
  1556.     single PK Kerberos extension is needed to address the goals of PKINIT &
  1557.     PKDA.                                                                  
  1558.  
  1559.   "Kerberos Change Password Protocol", M. Horowitz, 03/10/1997, 
  1560.   <draft-ietf-cat-kerb-chg-password-00.txt>                                
  1561.  
  1562.     The Kerberos V5 protocol [RFC1510] does not describe any mechanism for 
  1563.     users to change their own passwords.  In order to promote 
  1564.     interoperability between workstations, personal computers, terminal 
  1565.     servers, routers, and KDC's from multiple vendors, a common password 
  1566.     changing protocol is required.                                         
  1567.  
  1568.   "Integrity Protection for the Kerberos Error Message", G. Tsudik, B. 
  1569.   Tung, M. Hur, A. Medvinsky, 03/26/1997, 
  1570.   <draft-ietf-cat-kerberos-err-msg-00.txt>                                 
  1571.  
  1572.     The Kerberos error message, as defined in RFC 1510, is transmitted to 
  1573.     the client without any integrity assurance.  Therefore, the client has 
  1574.     no means to distinguish between a valid error message sent from the KDC
  1575.     and one sent by an attacker.  This draft describes a method for 
  1576.     assuring the integrity of Kerberos error messages, and proposes a 
  1577.     consistent format for the e-data field in the KRB_ERROR message.  This 
  1578.     e-data format enables the storage of cryptographic checksums by 
  1579.     providing an extensible mechanism for specifying e-data types.         
  1580.  
  1581.   "The Kerberos Network Authentication Service (V5)", Theodore Ts'o, 
  1582.   Clifford Neuman, 07/14/1997, <draft-ietf-cat-kerberos-revisions-00.txt>  
  1583.  
  1584.     This document provides an overview and specification of Version  5  of 
  1585.     the Kerberos protocol, and updates RFC1510 to clarify aspects of the 
  1586.     protocol and its  intended  use  that require  more  detailed or 
  1587.     clearer explanation than was provided in RFC1510.  This document is 
  1588.     intended  to  provide  a detailed description of the protocol, suitable
  1589.     for implementation, together with descriptions of the appropriate use 
  1590.     of protocol messages and fields within those messages.                 
  1591.  
  1592.   "Encryption using KEA and SKIPJACK", P. Yee, Russ Housley, W. Nace, 
  1593.   07/21/1997, <draft-ietf-cat-ftpkeasj-00.txt>                             
  1594.  
  1595.     This document defines a method to encrypt a file transfer using the FTP
  1596.     specification RFC 959, 'FILE TRANSFER PROTOCOL (FTP)' (October 1985) 
  1597.     and the work in progress document 'FTP Security Extensions' 
  1598.     draft-ietf-cat-ftpsec-09.txt[1].  This method will use the Key Exchange
  1599.     Algorithm (KEA) to give mutual authentication and establish the data 
  1600.     encryption keys.  SKIPJACK is used to encrypt file data and the FTP 
  1601.     command channel.                                                       
  1602.  
  1603.   "FTP Authentication Using DSA", P. Yee, Russ Housley, W. Nace, 
  1604.   07/21/1997, <draft-ietf-cat-ftpdsaauth-00.txt>                           
  1605.  
  1606.     This document defines a method to secure file transfers using the FTP 
  1607.     specification RFC 959, 'FILE TRANSFER PROTOCOL (FTP)' (October 1985) 
  1608.     and the work in progress document 'FTP Security Extensions' 
  1609.     Draft-ietf-cat-ftpsec-09.txt[1].  This method will use the extensions 
  1610.     proposed in the 'FTP Security Extensions' Draft document along with a 
  1611.     public/private digital signature.                                      
  1612.  
  1613.   "Anonymous Credentials in Kerberos", J. Cargille, M. Hur, A. Medvinsky, 
  1614.   09/22/1997, <draft-ietf-cat-kerberos-anoncred-00.txt>                    
  1615.  
  1616.     This document defines the concept of anonymous Kerberos
  1617.         credentials, and describes how such credentials can be securely
  1618.         obtained from a Kerberos KDC via the PKINIT extension.  This draft
  1619.         defines no new mechanisms or protocols; instead, it defines the
  1620.         concepts and proposes usage and naming conventions.                
  1621.  
  1622.   "Generic Security Service Application Program Interface, Version 2",, 
  1623.   09/23/1997, <draft-ietf-cat-rfc2078bis-00.txt>                           
  1624.  
  1625.        The Generic Security Service Application Program Interface 
  1626.     (GSS-API),
  1627.        Version 2, as defined in RFC-2078, provides security services to
  1628.        callers in a generic fashion, supportable with a range of underlying
  1629.        mechanisms and technologies and hence allowing source-level
  1630.        portability of applications to different environments. This
  1631.        specification defines GSS-API services and primitives at a level
  1632.        independent of underlying mechanism and programming language
  1633.        environment, and is to be complemented by other, related   
  1634.        specifications:
  1635.      
  1636.           documents defining specific parameter bindings for particular
  1637.           language environments
  1638.      
  1639.           documents defining token formats, protocols, and procedures to be
  1640.           implemented in order to realize GSS-API services atop particular
  1641.           security mechanisms
  1642.      
  1643.        This Internet-Draft revises RFC-2078, making specific, incremental
  1644.        changes in response to implementation experience and liaison        
  1645.     requests. It is intended, therefore, that this draft or a successor
  1646.        version thereto will become the basis for subsequent progression of
  1647.        the GSS-API specification on the standards track.                   
  1648.  
  1649.   "User to User Kerberos Authentication using GSS-API Preliminary Draft", 
  1650.   Michael Swift, 10/27/1997, <draft-ietf-cat-user2user-00.txt>             
  1651.  
  1652.       This draft proposes a simple extension to the Kerberos
  1653.       GSS-API mechanism to support user to user authentication
  1654.       both in the case where the client application explicitly
  1655.       requests user to user authentication and when it does not
  1656.       know whether the server supports user to user
  1657.       authentication.                                                      
  1658.  
  1659.   "Kerberos over IPv6", Assar Westerlund, 10/29/1997, 
  1660.   <draft-ietf-cat-krb5-ipv6-00.txt>                                        
  1661.  
  1662.        This document specifies the address types and transport types
  1663.        necessary for using Kerberos [RFC1510] over IPv6 [RFC1883].         
  1664.  
  1665. Dynamic Host Configuration (dhc)
  1666. --------------------------------
  1667.  
  1668.   "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", C. Perkins, J. 
  1669.   Bound, 05/28/1997, <draft-ietf-dhc-dhcpv6-10.txt>                        
  1670.  
  1671.     The Dynamic Host Configuration Protocol (DHCPv6) provides a framework 
  1672.     for passing configuration information, via extensions, to IPv6 nodes.  
  1673.     It offers the capability of automatic allocation of reusable network 
  1674.     addresses and additional configuration flexibility.  This protocol 
  1675.     should be considered a stateful counterpart to the IPv6 Stateless 
  1676.     Address Autoconfiguration protocol specification.                      
  1677.  
  1678.   "Interaction between DHCP and DNS", Y Rekhter, 05/19/1997, 
  1679.   <draft-ietf-dhc-dhcp-dns-04.txt>                                         
  1680.  
  1681.     DHCP provides a powerful mechanism for IP host autoconfiguration.  
  1682.     However, the autoconfiguration provided by DHCP does not include 
  1683.     updating DNS, and specifically updating the name to address and address
  1684.     to name mappings maintained by DNS.                                    
  1685.     This document specifies how DHCP clients and servers should use the 
  1686.     Dynamic DNS Updates mechanism to update the DNS name to address and 
  1687.     address to name mapping, so that the mappings for DHCP clients would be
  1688.     consistent with the IP addresses that the clients acquire via DHCP.    
  1689.  
  1690.   "An Extension to the DHCP Option Codes", Ralph Droms, 07/25/1997, 
  1691.   <draft-ietf-dhc-options-opt127-03.txt>                                   
  1692.  
  1693.     The Dynamic Host Configuration Protocol (DHCP) provides a framework for
  1694.     passing configuration information to hosts on a TCP/IP network.  This 
  1695.     document defines a new option to extend the available option codes.    
  1696.  
  1697.   "An option for FQDNs in DHCP options", Ralph Droms, Y Rekhter, 
  1698.   07/25/1997, <draft-ietf-dhc-fqdn-opt-03.txt>                             
  1699.  
  1700.     DHCP [DHCP] can be used to automate the process of configuring TCP/IP 
  1701.     host computers.  However, some of the DHCP options carry IP addresses 
  1702.     rather than Fully Qualified Domain Names (FQDN). Use of IP addresses 
  1703.     constrains the DHCP client to use the addresses that were in use at the
  1704.     time the client received its configuration information; these addresses
  1705.     may change over time, (e.g., a server may be assigned a new IP 
  1706.     address), so that the IP addresses used by the client may become 
  1707.     invalid.                        An alternative to passing IP addresses 
  1708.     is to pass FQDNs instead of (numeric) IP addresses.  Doing this allows 
  1709.     a client to defer binding between a particular network entity (e.g., a 
  1710.     server) and its IP address until run time.  As stated in 
  1711.     [Carpenter:96], 'Deferring the binding avoids the risk of changed 
  1712.     mapping between IP addresses and specific network entities (due to 
  1713.     changing addressing information).  Moreover, reliance on FQDNs (rather 
  1714.     than IP addresses) also localizes to the DNS the changes needed to deal
  1715.     with changing addressing information due to renumbering.'     This 
  1716.     document defines a new DHCP option that allows the use of FQDNs instead
  1717.     of IP addresses in DHCP options.                                       
  1718.  
  1719.   "Authentication for DHCP Messages", Ralph Droms, 08/28/1997, 
  1720.   <draft-ietf-dhc-authentication-04.txt>                                   
  1721.  
  1722.        The Dynamic Host Configuration Protocol (DHCP) [1] provides a
  1723.        framework for passing configuration information to hosts on a TCP/IP
  1724.        network.  In some situations, network administrators may wish to
  1725.        constrain the allocation of addresses to authorized hosts.
  1726.        Additionally, some network administrators may wish to provide for
  1727.        authentication of the source and contents of DHCP messages.  This
  1728.        document defines a new DHCP option through which authorization
  1729.        tickets can be easily generated and newly attached hosts with proper
  1730.        authorization can be automatically configured from an authenticated
  1731.        DHCP server.                                                        
  1732.  
  1733.   "Extensions for the Dynamic Host Configuration Protocol for IPv6", C. 
  1734.   Perkins, 08/04/1997, <draft-ietf-dhc-v6exts-07.txt>                      
  1735.  
  1736.     The Dynamic Host Configuration Protocol for IPv6 [4] (DHCPv6)
  1737.        provides a framework for passing configuration information to hosts
  1738.        on a TCP/IP network.  Configuration parameters and other control
  1739.        information are carried in typed data items that are stored in the
  1740.        'extensions' field of the DHCPv6 message.  The data items themselves
  1741.        are also called 'extensions.'
  1742.      
  1743.        This document specifies the current set of DHCPv6 extensions.  This
  1744.        document will be periodically updated as new extensions are defined.
  1745.        Each superseding document will include the entire current list of
  1746.        valid extensions.                                                   
  1747.  
  1748.   "DHCP Options for Service Location Protocol", C. Perkins, 05/12/1997, 
  1749.   <draft-ietf-dhc-slp-02.txt>                                              
  1750.  
  1751.     The Dynamic Host Configuration Protocol provides a framework for 
  1752.     passing configuration information to hosts on a TCP/IP network. 
  1753.     Entities using the Service Location Protocol need to find out the 
  1754.     address of Directory Agents in order to transact messages.  In certain 
  1755.     other instances they may need to discover the correct scope to be used 
  1756.     in conjunction with the service attributes which are exchanged using 
  1757.     the Service Location Protocol.                                         
  1758.  
  1759.   "The User Class Option for DHCP", Ralph Droms, G. Stump, 03/24/1997, 
  1760.   <draft-ietf-dhc-userclass-01.txt>                                        
  1761.  
  1762.     This option is used by a DHCP client to optionally identify the type or
  1763.     category of user or applications it represents.  The information 
  1764.     contained in this option is an NVT ASCII text object that represents 
  1765.     the user class of which the client is a member.                        
  1766.  
  1767.   "DHCP Option for IEEE 1003.1 POSIX Timezone Specifications", M. Carney, 
  1768.   07/30/1997, <draft-ietf-dhc-timezone-03.txt>                             
  1769.  
  1770.     The Dynamic Host Configuration Protocol (DHCP) [1] provides a framework
  1771.     for passing configuration information to hosts on a TCP/IP network. 
  1772.     This document defines a new option to extend the available option codes
  1773.     [3].                                                                   
  1774.  
  1775.   "An Inter-server Protocol for DHCP", Ralph Droms, R. Cole, K. Kinnear, 
  1776.   08/04/1997, <draft-ietf-dhc-interserver-02.txt>                          
  1777.  
  1778.     The DHCP protocol is designed to allow for multiple DHCP servers, so 
  1779.     that reliability of DHCP service can be improved through the use of 
  1780.     redundant servers.  To provide redundant service, multiple DHCP servers
  1781.     must carry the same information about assigned IP addresses and 
  1782.     parameters; i.e., the servers must be configured with the same 
  1783.     bindings.  Because DHCP servers may dynamically assign new addresses or
  1784.     configuration parameters, or extend the lease on an existing address 
  1785.     assignment, the bindings on some servers may become out of date.  The 
  1786.     DHCP inter-server protocol provides an automatic mechanism for 
  1787.     synchronization of the bindings stored on a set of cooperating DHCP 
  1788.     servers.  The underlying capabilities of the DHCP inter-server protocol
  1789.     required for multiple server cache replications are based upon the 
  1790.     Server Cache Synchronization Protocol (SCSP).                          
  1791.  
  1792.   "DHCP Relay Agent Information Option", M. Patrick, 08/01/1997, 
  1793.   <draft-ietf-dhc-agent-options-02.txt>                                    
  1794.  
  1795.        Newer high-speed public Internet access technologies call for a
  1796.        high-speed modem to have a LAN attachment to one or more user hosts.
  1797.        It is advantageous to use DHCP to assign user host IP addresses in
  1798.        this environment, but a number of security and scaling problems 
  1799.     arise
  1800.        with such 'public' DHCP use.  This draft calls for the definition of
  1801.        a 'DHCP Relay Agent Information' option that is appended to a DHCP
  1802.        packet forwarded from a client to a server by a relay agent.  The
  1803.        Server may or may not use the information in the the Relay Agent
  1804.        Information option; in either case, it echoes back the option
  1805.        verbatim in server-to-client replies.
  1806.      
  1807.        The 'Relay Agent Information' option contains sub-options that 
  1808.     convey
  1809.        information known by the relay agent.  The initial sub-options are
  1810.        defined for a relay agent that is co-located in a public circuit
  1811.        access unit.  These include a 'circuit ID' for the incoming circuit
  1812.        and a 'remote ID' which provides a trusted identifier for the remote
  1813.        high-speed modem.
  1814.                                                                            
  1815.  
  1816.   "Multicast address allocation extensions options", B. Patel, M. Shah, 
  1817.   08/01/1997, <draft-ietf-dhc-multopt-01.txt>                              
  1818.  
  1819.     This document describes host configuration options that may be used
  1820.        by multicast address allocation protocols[3]. The options include
  1821.        critical information such as the IP address (unicast or multicast)
  1822.        of the multicast address allocation server(s) and a list of
  1823.        multicast scopes supported by respective servers. These options are
  1824.        designed to work with the extensions to DHCP [1] servers to support
  1825.        multicast address allocation (described in a separate draft),
  1826.        however, their use may not be limited to the above protocol.        
  1827.  
  1828.   "Multicast address allocation extensions to the Dynamic Host 
  1829.   Configuration Protocol", B. Patel, M. Shah, 08/18/1997, 
  1830.   <draft-ietf-dhc-mdhcp-02.txt>                                            
  1831.  
  1832.        The Dynamic Host Configuration Protocol (DHCP) provides a framework
  1833.        for passing configuration information to hosts on a TCP/IP network.
  1834.        The multicast extensions to DHCP add additional capability of
  1835.        dynamic allocation of the multicast addresses and additional
  1836.        configuration options.                                              
  1837.  
  1838.   "DSCP: Dynamic Subnet Configuration Protocol", K. Taniguchi, T. Nishida, 
  1839.   03/24/1997, <draft-ietf-dhc-dyn-subnet-conf-00.txt>                      
  1840.  
  1841.     The Dynamic Subnet Configuration Protocol (DSCP) provides a framework 
  1842.     for passing configuration information to administrative servers on a 
  1843.     TCP/IP network which allows dynamic subnet configuration. Examples of 
  1844.     administrative servers, which are DSCP clients, are a network 
  1845.     administrator's host, DHCP server, etc.  DSCP is built on a client 
  1846.     server model.  The DSCP server allocates subnet configuration 
  1847.     parameters to dynamically configured subnetworks.  DSCP is an extension
  1848.     of DHCP [1,2]. This document describes DSCP model and defines a new 
  1849.     DHCP options to allow the subnet configuration dynamically.            
  1850.  
  1851.   "The Server Identification Option for DHCP", G. Stump, P. Gupta, 
  1852.   03/24/1997, <draft-ietf-dhc-sio-00.txt>                                  
  1853.  
  1854.     This option is provided by DHCP servers to DHCP clients to identify the
  1855.     origin of a DHCPOFFER -- on a basis other than a server's IP address --
  1856.     so that a DHCP client may optionally select from among multiple offers 
  1857.     based on a client's preference to a particular DHCP server(s).  The 
  1858.     information contained in this option is a hex value indicating the 
  1859.     assigned identification of the server originating the DHCPOFFER in 
  1860.     which this option is contained.                                        
  1861.  
  1862.   "The Server Selection Option for DHCP", G. Stump, P. Gupta, 03/24/1997, 
  1863.   <draft-ietf-dhc-sso-00.txt>                                              
  1864.  
  1865.     This option is provided by DHCP servers to DHCP clients so that clients
  1866.     may optionally select from among multiple offers received from DHCP 
  1867.     servers in the network based on a network-administrated preference 
  1868.     system.  The information contained in this option is a hex value that 
  1869.     represents the priority of the offer in which this option is contained.
  1870.  
  1871.   "Security Architecture for DHCP", O. Gudmundsson, 08/04/1997, 
  1872.   <draft-ietf-dhc-security-arch-01.txt>                                    
  1873.  
  1874.     This document addresses the general security requirements of both v4 
  1875.     and v6 versions of DHCP. This document lists security requirements and 
  1876.     proposes as security model, which meets scaling requirements, security 
  1877.     requirements and efficiency requirements.                              
  1878.     The proposed security model uses public key cryptography and a proposed
  1879.     trusted key distribution mechanism to authenticate clients and servers.
  1880.     The authentication protocol can also exchange keying material for more 
  1881.     efficiently protecting successive communication between client and 
  1882.     server.  The security model also addresses securing relay agents.      
  1883.  
  1884.   "An Inter-server Protocol for DHCP", Ralph Droms, R. Cole, K. Kinnear, 
  1885.   04/14/1997, <draft-ietf-dhc-interserver-alt-00.txt>                      
  1886.  
  1887.     The DHCP protocol is designed to allow for multiple DHCP servers, so 
  1888.     that reliability of DHCP service can be improved through the use of 
  1889.     redundant servers.  To provide redundant service, all of the DHCP 
  1890.     servers must be configured with the same information about assigned IP 
  1891.     addresses and parameters; i.e., all of the servers must be configured 
  1892.     with the same bindings.  Because DHCP servers may dynamically assign 
  1893.     new addresses or configuration parameters, or extend the lease on an 
  1894.     existing address assignment, the bindings on some servers may become 
  1895.     out of date.  The DHCP inter-server protocol provides an automatic 
  1896.     mechanism for synchronization of the bindings stored on a set of 
  1897.     cooperating DHCP servers.               This draft is a direct 
  1898.     extension of draft-ietf-dhc-interserver-00.txt, but has been renamed 
  1899.     draft-ietf-dhc-interserver-alt-00.txt since an alternative proposal 
  1900.     (also a direct extension of draft-ietf-dhc-interserver-00.txt but in a 
  1901.     different direction) exists named draft-ietf-dhc-interserver-01.txt.   
  1902.  
  1903.   "The Named Pool Request Option for DHCP", K. McGrew, 05/14/1997, 
  1904.   <draft-ietf-dhc-namedpool-00.txt>                                        
  1905.  
  1906.     This option is used by a DHCP client to optionally identify the 
  1907.     specific named pool from which it should be assigned an IP address.  
  1908.     The information contained in this option is an ASCII text object that 
  1909.     represents the named pool from which the DHCP server assign an IP 
  1910.     address to the DHCP client.                                            
  1911.  
  1912.   "Netware/IP Domain Name and Information", Ralph Droms, K. Fong, 
  1913.   10/30/1997, <draft-ietf-dhc-netware-options-01.txt>                      
  1914.  
  1915.     The Dynamic Host Configuration Protocol (DHCP) [RFC 2131] provides a
  1916.        framework for passing configuration information to hosts on a TCP/IP
  1917.        network. DHCP includes options for specific configuration parameters
  1918.        [RFC 2132].  This document defines options that carry NetWare/IP
  1919.        domain name and NetWare/IP sub-options to DHCP clients.             
  1920.  
  1921.   "Securing DHCP", B. Patel, 07/30/1997, 
  1922.   <draft-ietf-dhc-securing-dhc-00.txt>                                     
  1923.  
  1924.     This proposal describes methods of securing DHCP based on IETF DHCP and
  1925.     IPSEC protocols. This protocol achieves security goals for DHCP client 
  1926.     and servers without having to define a new security protocol. Instead, 
  1927.     it first bootstraps the DHCP client in un-trusted mode using existing 
  1928.     DHCP protocol and then proceeds to secure configuration of the client 
  1929.     using existing DHCP and IP protocol features.                          
  1930.  
  1931.   "Subnet Selection Option for DHCP", P. Gupta, W. Mark Townsley, 
  1932.   07/30/1997, <draft-ietf-dhc-subsel-00.txt>                               
  1933.  
  1934.     The Subnet Selections option is provided by a DHCP client to DHCP a
  1935.     server as an indication to which subnet or subnets to select an address
  1936.     from for the client's lease. When present, the DHCP server will use 
  1937.     this value as an indication to which configured subnet pool of 
  1938.     addresses to select from, effectively divorcing the giaddr of its 
  1939.     overloaded subnet selection function for a packet forwarded by a DHCP 
  1940.     relay agent. The giaddr is retains its function as the address for the 
  1941.     DHCP server to send replies to. 
  1942.     
  1943.     An application for this new option would be to allow a Network Access 
  1944.     Server (NAS) acting as DHCP proxy on behalf of a large number of 
  1945.     dial-in 
  1946.     users to obtain an address that is in the desired subnet(s) for the 
  1947.     dial 
  1948.     users without having to configure multiple giaddr values at the NAS, or
  1949.     requiring the NAS to utilize an address within each subnet.            
  1950.  
  1951.   "The Domain Search Option for DHCP", G. Stump, P. Gupta, 08/04/1997, 
  1952.   <draft-ietf-dhc-domsrch-00.txt>                                          
  1953.  
  1954.        The Dynamic Host Configuration Protocol (DHCP) [1] provides a
  1955.        framework for passing configuration information to hosts on a TCP/IP
  1956.        network. This document defines a new option which is passed form the
  1957.        DHCP server to the DHCP Client to configure the domain search list
  1958.        which is used by the clients to resolve hostnames in the Domain Name
  1959.        System.
  1960.                                                                            
  1961.  
  1962. Distributed Management (disman)
  1963. -------------------------------
  1964.  
  1965.   "Definitions of Managed Objects for the Delegation of Management 
  1966.   Scripts", D. Levi, J. Schoenwaelder, 03/12/1997, 
  1967.   <draft-ietf-disman-script-mib-01.txt>                                    
  1968.  
  1969.     This memo defines an experimental portion of the Management Information
  1970.     Base (MIB) for use with network management protocols in the Internet 
  1971.     community. In particular, it describes a set of managed objects that 
  1972.     allows the delegation of management scripts to mid-level managers.     
  1973.     This memo does not specify a standard for the Internet community.      
  1974.  
  1975.   "Distributed Management Framework", Steven Waldbusser, Bob Stewart, Andy 
  1976.   Bierman, M. Greene, 01/03/1997, <draft-ietf-disman-framework-00.txt>     
  1977.  
  1978.     This memo defines a distributed management architecture for use with 
  1979.     the SNMP network management architecture.                              
  1980.     This memo does not specify a standard for the Internet community.      
  1981.  
  1982.   "Expression MIB", Bob Stewart, 06/04/1997, 
  1983.   <draft-ietf-disman-express-mib-02.txt>                                   
  1984.  
  1985.     This memo defines an experimental portion of the Management Information
  1986.     Base (MIB) for use with network management protocols in the Internet 
  1987.     community.  In particular, it describes managed objects used for 
  1988.     managing expressions of MIB objects.                                   
  1989.  
  1990.   "Management Target MIB", Bob Stewart, 05/02/1997, 
  1991.   <draft-ietf-disman-mgt-target-mib-01.txt>                                
  1992.  
  1993.     This memo defines an experimental portion of the Management Information
  1994.     Base (MIB) for use with network management protocols in the Internet 
  1995.     community.  In particular, it describes managed objects used for 
  1996.     managing a list of network management destinations (targets) and the 
  1997.     information needed to get to them and to group them.                   
  1998.  
  1999.   "Notification MIB", Bob Stewart, 05/02/1997, 
  2000.   <draft-ietf-disman-notify-mib-01.txt>                                    
  2001.  
  2002.     This memo defines an experimental portion of the Management Information
  2003.     Base (MIB) for use with network management protocols in the Internet 
  2004.     community.  In particular, it describes managed objects used for 
  2005.     managing SNMP notifications.                                           
  2006.  
  2007.   "Event MIB", Bob Stewart, 05/02/1997, 
  2008.   <draft-ietf-disman-event-mib-01.txt>                                     
  2009.  
  2010.     This memo defines an experimental portion of the Management Information
  2011.     Base (MIB) for use with network management protocols in the Internet 
  2012.     community.  In particular, it describes managed objects used for 
  2013.     managing monitoring of MIB objects and taking action through events.   
  2014.  
  2015. DNS IXFR, Notification, and Dynamic Update (dnsind)
  2016. ---------------------------------------------------
  2017.  
  2018.   "Classless IN-ADDR.ARPA delegation", G. de Groot, P. Vixie, H. Eidnes, 
  2019.   05/12/1997, <draft-ietf-dnsind-classless-inaddr-03.txt>                  
  2020.  
  2021.     This document describes a way to do IN-ADDR.ARPA delegation on 
  2022.     non-octet boundaries for address spaces covering fewer than 256 
  2023.     addresses.  The proposed method should thus remove one of the 
  2024.     objections to subnet on non-octet boundaries but perhaps more 
  2025.     significantly, make it possible to assign IP address space in smaller 
  2026.     chunks than 24-bit prefixes, without losing the ability to delegate 
  2027.     authority for the corresponding IN-ADDR.ARPA mappings.  The proposed 
  2028.     method is fully compatible with the original DNS lookup mechanisms 
  2029.     specified in [1], i.e. there is no need to modify the lookup algorithm 
  2030.     used, and there should be no need to modify any software which does DNS
  2031.     lookups either.                                The document also 
  2032.     discusses some operational considerations to provide some guidance in 
  2033.     implementing this method.                                              
  2034.  
  2035.   "The Kitchen Sink Resource Record", Don Eastlake, 04/28/1997, 
  2036.   <draft-eastlake-kitchen-sink-02.txt>                                     
  2037.  
  2038.     Periodically people are seized with a desire to put complex, bulky, 
  2039.     and/or obscurely structured data into the Domain Name System (DNS).  
  2040.     This draft defines a kitchen sink Resource Record that will satisfy 
  2041.     this lust by defining a new DNS resource record for the storage of 
  2042.     miscellaneous structured information.                                  
  2043.  
  2044.   "Negative Caching of DNS Queries (DNS NCACHE)", M. Andrews, 10/27/1997, 
  2045.   <draft-ietf-dnsind-ncache-08.txt>                                        
  2046.  
  2047.                [RFC1034] provided a description of how to cache negative
  2048.                responses.  It however had a fundamental flaw in that it did
  2049.     not
  2050.                allow a name server to hand out those cached responses to 
  2051.     other
  2052.                resolvers, thereby greatly reducing the effect of the 
  2053.     caching.
  2054.                This document addresses issues raise in the light of 
  2055.     experience
  2056.                and replaces [RFC1034 Section 4.3.4].
  2057.      
  2058.                Negative caching was an optional part of the DNS 
  2059.     specification
  2060.                and deals with the caching of the non-existence of an RRset
  2061.                [RFC2181] or domain name.
  2062.      
  2063.                Negative caching is useful as it reduces the response time 
  2064.     for
  2065.                negative answers.  It also reduces the number of messages 
  2066.     that
  2067.                have to be sent between resolvers and name servers hence 
  2068.     overall
  2069.                network traffic.  A large proportion of DNS traffic on the  
  2070.     Internet could be eliminated if all resolvers implemented
  2071.                negative caching.  With this in mind negative caching should
  2072.     no
  2073.                longer be seen as an optional part of a DNS resolver.       
  2074.  
  2075.   "Test and Example Top Level Domain Names", D. Eastlake, Aliza Panitz, 
  2076.   10/31/1997, <draft-ietf-dnsind-test-tlds-04.txt>                         
  2077.  
  2078.     To reduce the likelihood of conflict and confusion, a number of top
  2079.        level domain names are reserved for use in private testing, as
  2080.        examples in documentation, and the like.                            
  2081.  
  2082.   "Local DNS Names", Don Eastlake, 10/15/1997, 
  2083.   <draft-ietf-dnsind-local-names-02.txt>                                   
  2084.  
  2085.        A set of second level domain names are defined under a new top level
  2086.        domain name such that local private DNS zones can be maintained
  2087.        similar to the private IP addresses reserved in RFC 1918 but which
  2088.        locally appear to be part of the global DNS name tree.  Additional
  2089.        second level domain names are assigned under this TLD for loopback
  2090.        addresses and IPv6 link and site local addresses.                   
  2091.  
  2092. Domain Name System Security (dnssec)
  2093. ------------------------------------
  2094.  
  2095.   "Mapping Autonomous Systems Number into the Domain Name System", Don 
  2096.   Eastlake, 08/02/1997, <draft-ietf-dnssec-as-map-05.txt>                  
  2097.  
  2098.        One requirement of secure routing is that independent routing
  2099.        entities, such as those identified by Internet Autonomous System
  2100.        Numbers, be able to authenticate messages to each other.  Additions
  2101.        have developed to the Domain Name System to enable it to be used for
  2102.        authenticated public key distribution [RFC 2065].  This draft maps
  2103.        all Autonomous System numbers into DNS Domain Names so that the DNS
  2104.        security can be used to distribute their public keys.
  2105.     
  2106.        [Changes from previous version are to accommodate AS numbers larger
  2107.        than 16 bits and to delegate on decimal boundaries rather than 
  2108.     binary
  2109.        boundaries.]
  2110.                                                                            
  2111.  
  2112.   "Detached Domain Name System Information", Don Eastlake, 03/26/1997, 
  2113.   <draft-ietf-dnssec-ddi-02.txt>                                           
  2114.  
  2115.     A standard format is defined for representing detached DNS information.
  2116.     This is anticipated to be of use for storing information retrieved from
  2117.     the Domain Name System (DNS), including security information, in 
  2118.     archival contexts or contexts not connected to the Internet.           
  2119.  
  2120.   "The DNS Inverse Key Domain", Don Eastlake, 03/27/1997, 
  2121.   <draft-ietf-dnssec-in-key-00.txt>                                        
  2122.  
  2123.     Proposed Standard protocol extensions now exist to the Domain Name 
  2124.     System (DNS) to authenticate the data in DNS and provide key 
  2125.     distribution services (RFC 2065).  This draft proposes a special 
  2126.     in-key.int domain which would allow entities to be found from their 
  2127.     keys if they have voluntarily registered them in that domain.          
  2128.  
  2129.   "Storage of Diffie-Hellman Keys in the Domain Name System", Don Eastlake,
  2130.   06/02/1997, <draft-ietf-dnssec-dhk-00.txt>                               
  2131.  
  2132.     A standard method for storing Diffie-Hellman keys in the Domain Name 
  2133.     System is described which utilizes DNS KEY resource records.           
  2134.  
  2135.   "Domain Name System Security Extensions", Don Eastlake, 08/25/1997, 
  2136.   <draft-ietf-dnssec-secext2-01.txt>                                       
  2137.  
  2138.     Extensions to the Domain Name System (DNS) are described that provide
  2139.     data integrity and authentication to security aware resolvers or
  2140.     applications through the use of cryptographic digital signatures.
  2141.     These digital signatures are included in secured zones as resource
  2142.     records.  Security can also be provided even through non-security
  2143.     aware DNS servers in many cases.
  2144.     
  2145.     The extensions provide for the storage of authenticated public keys
  2146.     in the DNS.  This storage of keys can support general public key
  2147.     distribution services as well as DNS security.  The stored keys
  2148.     enable security aware resolvers to learn the authenticating key of
  2149.     zones in addition to those for which they are initially configured.
  2150.     Keys associated with DNS names can be retrieved to support other
  2151.     protocols.  Provision is made for a variety of key types and
  2152.     algorithms.
  2153.     
  2154.     In addition, the security extensions provide for the optional
  2155.     authentication of DNS protocol transactions and requests.
  2156.      
  2157.     This document incorporates feedback from implementors and potential
  2158.     users to RFC 2065.                                                     
  2159.  
  2160.   "DSA KEYs and SIGs in the Domain Name System", Don Eastlake, 09/10/1997, 
  2161.   <draft-ietf-dnssec-dss-00.txt>                                           
  2162.  
  2163.        A standard method for storing US Government Digital Signature
  2164.        Algorithm keys and signatures in the Domain Name System is described
  2165.        which utilizes DNS KEY and SIG resource records.                    
  2166.  
  2167.   "Storing Certificates in the Domain Name System", O. Gudmundsson, D. 
  2168.   Eastlake, 09/12/1997, <draft-ietf-dnssec-certs-00.txt>                   
  2169.  
  2170.        Cryptographic public key are frequently published and their
  2171.        authenticity demonstrated by certification systems.  A CERT resource
  2172.        record (RR) is defined so that such certificates and certificate
  2173.        revocation lists can be conveniently stored in the Domain Name 
  2174.     System
  2175.        (DNS).
  2176.      
  2177.        RFC 2065 specifies a Proposed Standard for storing cryptographic
  2178.        public keys in the DNS via the KEY resource record (RR).   In
  2179.        addition to defining the CERT RR as above, a certificate flag bit is
  2180.        also allocated out of the KEY RR flag field to indicate that a key
  2181.        may be authenticated by one or more CERT RRs stored under the same
  2182.        owner name as the KEY RR.
  2183.      
  2184.        A separate document, draft-ietf-dnssec-indirect-key-00.txt, provides
  2185.        aaditional ways of references keys or certificates within or outside
  2186.        the DNS.                                                            
  2187.  
  2188.   "Indirect Keys in the Domain Name System", D. Eastlake, 09/12/1997, 
  2189.   <draft-ietf-dnssec-indirect-key-00.txt>                                  
  2190.  
  2191.        RFC 2065 defines a means for storing cryptogrpahic public keys in 
  2192.     the
  2193.        Domain Name System.  An additional code point is defined for the KEY
  2194.        resource record (RR) algorithm field to indicate that the key itself
  2195.        is not stored in the KEY RR but is pointed to by the KEY RR.
  2196.        Encodings to indicate different types of key and pointer formats are
  2197.        specified.                                                          
  2198.  
  2199. Detailed Revision/Update of Message Standards (drums)
  2200. -----------------------------------------------------
  2201.  
  2202.   "Simple Mail Transfer Protocol", John Klensin, 08/05/1997, 
  2203.   <draft-ietf-drums-smtpupd-06.txt>                                        
  2204.  
  2205.     This document is a self-contained specification of the basic protocol
  2206.     for the Internet electronic mail transport, consolidating and
  2207.     updating
  2208.     
  2209.      * the original SMTP specification of RFC 821 [RFC-821],
  2210.      * Domain name system requirements and implications for mail
  2211.        transport from RFC 1035 [RFC-DNS] and RFC 974 [RFC974],
  2212.      * the clarifications and applicability statements in
  2213.          RFC 1123 [RFC-1123], and
  2214.      * material drawn from the SMTP Extension mechanisms [SMTPEXT].
  2215.     
  2216.     It replaces RFC 821, RFC 974, and the mail transport materials of RFC
  2217.     1123.  However, RFC 821 specifies some features that are not in
  2218.     significant use in the Internet of the mid-1990s and (in appendices)
  2219.     some additional transport models.  Those sections are omitted here in
  2220.     the interest of clarity and brevity; readers needing them should
  2221.     refer to RFC 821.
  2222.      
  2223.     It also includes some additional material from RFC 1123 that required
  2224.     amplification.  This material has been identified in multiple ways,
  2225.     mostly by tracking flaming on the header-people list [HEADER-PEOPLE]
  2226.     and problems of unusual readings or interpretations that have turned
  2227.     up as the SMTP extensions have been deployed.  Where this
  2228.     specification moves beyond consolidation and actually differs from
  2229.     earlier documents, it supersedes them technically as well as
  2230.     textually.
  2231.      
  2232.     Although SMTP was designed as a mail transport and delivery protocol,
  2233.     this specification also contains information that is important to its
  2234.     use as a 'mail posting' protocol, as recommended for POP [RFC-POP2,
  2235.     RFC-POP3] and IMAP [RFC-IMAP4].
  2236.      
  2237.     Section ##2.3 provides definitions of terms specific to this
  2238.     document. Except when the historical terminology is necessary for
  2239.     clarity, this document uses the current 'client' and 'server'
  2240.     terminology to identify the sending and receiving SMTP processes,
  2241.     respectively.
  2242.      
  2243.     A companion document discusses message bodies and formats RFC 822,
  2244.     MIME, and their relationship - [MSGFMT].                               
  2245.  
  2246.   "Augmented BNF for Syntax Specifications: ABNF", Dave Crocker, P. 
  2247.   Overell, 10/17/1997, <draft-ietf-drums-abnf-05.txt>                      
  2248.  
  2249.     Internet technical specifications often need to define a format
  2250.     syntax and are free to employ whatever notation their authors
  2251.     deem useful.  Over the years, a modified version of Backus-Naur
  2252.     Form (BNF), called Augmented BNF (ABNF), has been popular among
  2253.     many Internet specifications.  It balances compactness and
  2254.     simplicity, with reasonable representational power.  In the early
  2255.     days of the Arpanet, each specification contained its own
  2256.     definition of ABNF.  This included the email specifications,
  2257.     RFC733 and then RFC822 which have come to be the common citations
  2258.     for defining ABNF.  The current document separates out that
  2259.     definition, to permit selective reference.  Predictably, it also
  2260.     provides some modifications and enhancements.
  2261.      
  2262.     The differences between standard BNF and ABNF involve naming
  2263.     rules, repetition, alternatives, order-independence, and value
  2264.     ranges.  Appendix A (Core) supplies rule definitions and encoding
  2265.     for a core lexical analyzer of the type common to several
  2266.     Internet specifications.  It is provided as a convenience and is
  2267.     otherwise separate from the meta language defined in the body of
  2268.     this document, and separate from its formal status.
  2269.                                                                            
  2270.  
  2271.   "Mail and Netnews Header Registration Procedure", J. Palme, 08/21/1997, 
  2272.   <draft-ietf-drums-MHRegistry-01.txt>                                     
  2273.  
  2274.     Various IETF standards and e-mail and netnews software products
  2275.     use various e-mail and netnews header fields. This document
  2276.     specifies a procedure for the registration of e-mail and netnews
  2277.     header field names, to reduce the risk that two different products
  2278.     use the same header name in different ways (homonyms) or that
  2279.     several different header names are used with identical meaning
  2280.     (synonyms).                                                            
  2281.  
  2282.   "Message Format Standard", P. Resnick, 06/24/1997, 
  2283.   <draft-ietf-drums-msg-fmt-02.txt>                                        
  2284.  
  2285.     This standard specifies a syntax for text messages that are sent 
  2286.     between computer users, within the framework of 'electronic mail' 
  2287.     messages. This standard supersedes the one specified in Request For 
  2288.     Comments 822, 'Standard for the Format of ARPA Internet Text Messages'.
  2289.     This standard only specifies a syntax for text messages. In particular,
  2290.     it makes no provision for the transmission of images, audio, or other 
  2291.     sorts of structured data in electronic mail messages. There are several
  2292.     extensions published, such as the MIME document series [MIME-IMT, 
  2293.     MIME-IMB], which describe mechanisms for the transmission of such data 
  2294.     through electronic mail, either by extending the syntax provided here 
  2295.     or by structuring such messages to conform to this syntax. These 
  2296.     mechanisms are outside of the scope of this standard.                  
  2297.     Note: Though this document uses the word 'standard' in both the title 
  2298.     and the body of the text, it is of course still an Internet Draft and 
  2299.     is NOT actually a standard until it has been approved and published as 
  2300.     an RFC.                                                                
  2301.  
  2302.   "Use of Reply-To in Internet E-Mail messages", Robert Elz, 10/30/1997, 
  2303.   <draft-ietf-drums-kre-reply-to-00.txt>                                   
  2304.  
  2305.        This draft forms part of a discussion on the appropriate use of the
  2306.        Reply-To header in e-mail messages.  This draft argues for one
  2307.        particular proposed definition of the Reply-To header.
  2308.      
  2309.        It is not intended that this document ever become anything more than
  2310.        an Internet-Draft.  If adopted, the text here, or a modified version
  2311.        of some parts of it, would be merged into the proposed replacement
  2312.        for RFC822.                                                         
  2313.  
  2314. Electronic Data Interchange-Internet Integration (ediint)
  2315. ---------------------------------------------------------
  2316.  
  2317.   "Requirements for Inter-operable Internet EDI", Rik Drummond, M. Jansson,
  2318.   C. Shih, 07/15/1997, <draft-ietf-ediint-req-03.txt>                      
  2319.  
  2320.     This document is a functional specification, discussing the 
  2321.     requirements for inter-operable EDI, with sufficient background 
  2322.     material to give an explanation for the EDI community of the Internet 
  2323.     and security related issues.                                           
  2324.  
  2325.   "MIME-based Secure EDI", Rik Drummond, M. Jansson, C. Shih, 07/15/1997, 
  2326.   <draft-ietf-ediint-as1-04.txt>                                           
  2327.  
  2328.     This document describes how to securely exchange EDI documents using 
  2329.     MIME and public key cryptography.                                      
  2330.  
  2331. Entity MIB (entmib)
  2332. -------------------
  2333.  
  2334.   "Entity MIB Extesions for Persistent Component Identification", Keith 
  2335.   McCloghrie, Andy Bierman, 09/17/1997, 
  2336.   <draft-bierman-entmib-compid-01.txt>                                     
  2337.  
  2338.     This memo defines an experimental portion of the Management Information
  2339.     Base (MIB) for use with network management protocols in the Internet
  2340.     community.  In particular, it describes managed objects used for
  2341.     managing physical topology identification and discovery.               
  2342.  
  2343. Internet Fax (fax)
  2344. ------------------
  2345.  
  2346.   "Tag Image File Format (TIFF) - Application F", G. Parsons, James 
  2347.   Rafferty, 09/22/1997, <draft-ietf-fax-tiff-04.txt>                       
  2348.  
  2349.     This document describes in detail the definition of TIFF-F that is
  2350.         used to store facsimile images.  The TIFF-F encoding has been
  2351.         folklore with no standard reference definition before this
  2352.         document.                                                          
  2353.  
  2354.   "File Format for Internet Fax", Steve Zilles, L. McIntyre, Dennis 
  2355.   Venable, Robert Buckley, 10/09/1997, <draft-ietf-fax-tiffplus-02.txt>    
  2356.  
  2357.     This Internet Draft describes the TIFF (Tag Image File Format)
  2358.     representation of image data specified by the ITU-T Recommendations for
  2359.     black-and-white and color facsimile. It formally defines Applications 
  2360.     W,
  2361.     F, J, C, P and M of the MIME Media Type image/tiff for use with 
  2362.     Internet
  2363.     Fax. Applications W, F and J describe the minimal, extended and 
  2364.     lossless
  2365.     JBIG modes for black-and-white fax. Applications C, P and M describe 
  2366.     the
  2367.     base JPEG, lossless JBIG and Mixed Raster Content modes for color and
  2368.     grayscale fax.                                                         
  2369.  
  2370.   "Tag Image File Format (TIFF) - image/tiff MIME Sub-type Registration", 
  2371.   Steve Zilles, G. Parsons, James Rafferty, 09/22/1997, 
  2372.   <draft-ietf-fax-tiff-reg-02.txt>                                         
  2373.  
  2374.     This document describes the registration of the MIME sub-type
  2375.       image/tiff.  The baseline encoding is defined by [TIFF].             
  2376.  
  2377.   "SMTP Service Extension for Immediate Delivery", Larry Masinter, N. 
  2378.   Joffe, Dan Wing, 10/15/1997, <draft-ietf-fax-smtp-session-00.txt>        
  2379.  
  2380.       This memo defines an extension to SMTP which provides a mechanism for
  2381.       requesting and verifying immediate message delivery over SMTP.       
  2382.  
  2383.   "PSTN and fax address format in e-mail services v3.4", C. Allocchio, 
  2384.   10/28/1997, <draft-ietf-fax-addressing-01.txt>                           
  2385.  
  2386.        Since the very first e-mail to fax gateway objects appeared, a
  2387.        number of different methods to specify a fax address into an
  2388.        e-mail address have been used by implementors.                      
  2389.  
  2390.   "Tag Image File Format (TIFF) - image/tiff-f           MIME Sub-type 
  2391.   Registration", G. Parsons, James Rafferty, 09/22/1997, 
  2392.   <draft-ietf-fax-tiff-f-reg-00.txt>                                       
  2393.  
  2394.     This document describes the registration of the MIME sub-type
  2395.       image/tiff-f.  The baseline encoding is defined by [TIFF].           
  2396.  
  2397.   "PROCEDURES FOR THE TRANSFER OF FACSIMILE DATA VIA INTERNET MAIL", Dave 
  2398.   Crocker, 10/27/1997, <draft-ietf-fax-itudc-00.txt>                       
  2399.  
  2400.     F.IFax, defines the service requirement for both real-time and
  2401.     store and forward facsimile over the Internet.  For store  and
  2402.     forward facsimile this Recommendation defines addressing, MIME
  2403.     encapsulation  of  document components and  data  formats  for
  2404.     those components..
  2405.      
  2406.     Store  and  forward  facsimile  uses  Internet  mail  standard
  2407.     protocols  for  posting, relaying and delivery  of  store  and
  2408.     forward facsimile document. It requires no changes to Internet
  2409.     standards  or  to  ITU  Facsimile  Recommendations.   Such  an
  2410.     approach  leads  to  a  system that can  be  used  universally
  2411.     without  changes  to  Internet servers or  other  intermediate
  2412.     systems between the sender and the recipient and which permits
  2413.     interworking  between facsimile store and  forward  users  and
  2414.     users of general Internet mail.                                        
  2415.  
  2416. Common Indexing Protocol (find)
  2417. -------------------------------
  2418.  
  2419.   "A Tagged Index Object for use in the Common Indexing Protocol", Roland 
  2420.   Hedberg, R. Moats, M. Wahl, B. Greenblatt, 09/23/1997, 
  2421.   <draft-ietf-find-cip-tagged-03.txt>                                      
  2422.  
  2423.             This document defines a mechanism by which information servers
  2424.        can exchange indices of information from their databases by making
  2425.        use of the Common Indexing Protocol (CIP).  This document defines 
  2426.     the
  2427.        structure of the index information being exchanged, as well as a the
  2428.        appropriate meanings for the headers that are defined in the Common
  2429.        Indexing Protocol.  It is assumed that the structures defined here
  2430.        can be used by X.500 DSAs, LDAP servers, whois++ servers, CCSO
  2431.        servers and many others.                                            
  2432.  
  2433.   "A CIP-based Centroid Exchange for LDAP", M. Wahl, 02/10/1997, 
  2434.   <draft-ietf-find-ldapc-00.txt>                                           
  2435.  
  2436.     This document describes how an LDAP server (the supplier) may transmit,
  2437.     through an out-of-band email, index information or attributes of its 
  2438.     naming context to another LDAP server (the consumer).  The consumer 
  2439.     server will make use of this information when determining whether the 
  2440.     supplier server is likely to have entries in that naming context which 
  2441.     match a particular search filter.  This assists the consumer in 
  2442.     processing subtree searches in distributed directories.                
  2443.  
  2444.   "CIP Index Object Format for SOIF Objects", Mike Schwartz, D. Hardy, M. 
  2445.   Bowman, E. Hardie, Duane Wessels, 10/31/1997, 
  2446.   <draft-ietf-find-cip-soif-02.txt>                                        
  2447.  
  2448.     The Common Indexing Protocol (CIP) allows servers to form a referral
  2449.     mesh for query handling by defining a mechanism by which cooperating
  2450.     servers exchange hints about the searchable indices they maintain.  The
  2451.     structure and transport of CIP are described in (Ref. 1), as are 
  2452.     general
  2453.     rules for the definition of index object types.  This document 
  2454.     describes
  2455.     SOIF, the Summary Object Interchange Format, as an index object type in
  2456.     the context of the CIP framework.  SOIF is a machine-readable syntax 
  2457.     for
  2458.     transmitting structured summary objects, currently used primarily in 
  2459.     the
  2460.     context of the World Wide Web.
  2461.      
  2462.     Query referral has often been dismissed as an ineffective strategy for
  2463.     handling searches of Web resources, and Web resources certainly present
  2464.     challenges not present in structured directory services like Rwhois.  
  2465.     In
  2466.     situations where a keyword-based free text search is desired, query
  2467.     referral is not likely to be effective because the query will probably
  2468.     be routed to every server participating in the referral mesh.  Where a
  2469.     search can be limited by reference to a specific resource attribute,
  2470.     however, query referral is an effective tool.  SOIF can be used to
  2471.     create such a known-attribute query mesh because it provides a method
  2472.     for associating attributes with net-addressable resources.
  2473.     
  2474.     Mic Bowman, Darren Hardy, Mike Schwartz, and Duane Wessels each
  2475.     contributed to the creation of the SOIF format and to the descriptions
  2476.     from which this draft is drawn; errors in this description of their 
  2477.     work
  2478.     are the responsibility of Edward Hardie and corrections should be
  2479.     directed accordingly.
  2480.                                                                            
  2481.  
  2482.   "Hierarchical Extensions to the Common Indexing Protocol", Chris Weider, 
  2483.   P. Leach, 07/15/1997, <draft-ietf-find-cip-hierarchy-01.txt>             
  2484.  
  2485.     This work explores what, in the parlance of the current CIP draft, is 
  2486.     called an index type -- specifically, a new kind of index that merges 
  2487.     indexing of  hierarchically named attribute-value entities (such as in 
  2488.     LDAP and RWHOIS) and ones without distinguished names (such as in 
  2489.     WHOIS++). It is based on a previous version of the CIP specification, 
  2490.     but that was just a convenient syntactical jumping off point. It is 
  2491.     intended to be orthogonal to the FIND working group task of  defining a
  2492.     framing syntax and functionality for a common indexing data wrapping 
  2493.     protocol, and that the concepts and protocol elements in this draft 
  2494.     should be able to be expressed in a manner consistent with the new CIP 
  2495.     framework at the appropriate time.                                     
  2496.  
  2497.   "Registration Procedures for SOIF Template Types", E. Hardie, 05/27/1997,
  2498.   <draft-ietf-find-soif-registry-00.txt>                                   
  2499.  
  2500.     The Summary Object Interchange Format [Ref. 1] was first defined by the
  2501.     Harvest Project [Ref 2.] in January 1994.  SOIF was derived from a 
  2502.     combination of the Internet Anonymous FTP Archives IETF Working Group 
  2503.     (IAFA) templates [Ref 3.] and the BibTeX bibliography format [Ref 4.]. 
  2504.     The combination was originally noted for its advantages of providing a 
  2505.     convenient and intuitive way for delimiting objects within a stream, 
  2506.     and setting apart the URL for easy object access or invocation, while 
  2507.     still preserving compatibility with IAFA templates.              SOIF 
  2508.     uses named template types to indicate the attributes which may be 
  2509.     contained within a particular summary object.  Within the context of a 
  2510.     single application, private agreement on the definition of template 
  2511.     types has been adequate.  As SOIF objects are moved among applications,
  2512.     however, the need for standard, well-specified, and easily identifiable
  2513.     template types increases.  This need is particularly intense in the 
  2514.     context of query referral, where knowledge of an attribute's definition
  2515.     and the allowed data types for specific values is crucial.  For a 
  2516.     discussion of this in the context of the Common Indexing Protocol, see 
  2517.     [Ref. 1].                                                              
  2518.  
  2519.   "CIP Transport Protocols", P. Leach, J. Allen, 06/10/1997, 
  2520.   <draft-ietf-find-cip-trans-00.txt>                                       
  2521.  
  2522.     This document specifies three protocols for transporting CIP requests, 
  2523.     responses and index objects, utilizing TCP, mail, and HTTP. The objects
  2524.     themselves are defined in [CIP-MIME] and the overall CIP architecture 
  2525.     is defined in [CIP-ARCH].                                              
  2526.  
  2527.   "MIME Object Definitions for the Common Indexing Protocol  (CIP)", M. 
  2528.   Mealling, J. Allen, 06/11/1997, <draft-ietf-find-cip-mime-00.txt>        
  2529.  
  2530.     The Common Indexing Protocol (CIP) is used to pass indexing information
  2531.     from server to server in order to facilitate query routing. The 
  2532.     protocol is comprised of several MIME objects being passed from server 
  2533.     to server. This document describes the definitions of those objects as 
  2534.     well as the methods and requirements needed to define a new index type.
  2535.  
  2536.   "The Architecture of the Common Indexing Protocol (CIP)", M. Mealling, J.
  2537.   Allen, 06/11/1997, <draft-ietf-find-cip-arch-00.txt>                     
  2538.  
  2539.     The Common Indexing Protocol (CIP) is used to pass indexing information
  2540.     from server to server in order to facilitate query routing. Query 
  2541.     routing is the process of redirecting and replicating queries through a
  2542.     distributed database system towards servers holding the desired 
  2543.     results. This document describes the CIP framework, including it's 
  2544.     architecture and the protocol specifics of exchanging indices.         
  2545.  
  2546. Frame Relay Service MIB (frnetmib)
  2547. ----------------------------------
  2548.  
  2549.   "Management Information Base for Frame Relay DTE Extensions for SVC's 
  2550.   over Frame Relay", D. Cochrane, 05/14/1997, 
  2551.   <draft-ietf-frnetmib-dte-svc-00.txt>                                     
  2552.  
  2553.     This memo defines a portion of the Management Information Base (MIB) 
  2554.     for use with network management protocols in TCP/IP-based internets.  
  2555.     In particular, it defines objects for managing Frame Relay Switched 
  2556.     Virtual Circuit's.  This memo does not specify a standard for the 
  2557.     Internet community.                                                    
  2558.  
  2559.   "Management Information Base for Frame Relay Data Compression", M. 
  2560.   Kashef, J. Colom, 07/08/1997, <draft-ietf-frnetmib-dcp-02.txt>           
  2561.  
  2562.     This memo defines a portion of the Management Information Base (MIB) 
  2563.     for use with network management protocols in TCP/IP-based internets.  
  2564.     In particular, it defines objects for managing Data Compression over a 
  2565.     Frame Relay virtual circuit.  This memo does not specify a standard for
  2566.     the Internet community.                                                
  2567.  
  2568.   "Definitions of Managed Objects for Frame Relay Service", Tracy Brown, D.
  2569.   Fowler, 03/20/1997, <draft-ietf-frnetmib-frs-mib-01.txt>                 
  2570.  
  2571.     This memo defines an extension to the Management Information Base (MIB)
  2572.     for use with network management protocols in TCP/IP-based internets.  
  2573.     In particular, it defines objects for managing the Frame Relay Service.
  2574.     This memo does not specify a standard for the Internet community.      
  2575.     This document entirely replaces RFC 1604.                              
  2576.  
  2577.   "Frame Relay Service Extensions MIB for Switched PVCs", B. Coutts, 
  2578.   02/10/1997, <draft-ietf-frnetmib-spvc-00.txt>                            
  2579.  
  2580.     This memo defines a portion of the Management Information Base (MIB) 
  2581.     for use with network management protocols in TCP/IP- based internets.  
  2582.     In particular, it defines objects for managing Frame Relay Switched 
  2583.     Permanent Virtual Circuits (SPVCs) as extensions to RFC 1604 [1].  This
  2584.     memo does not specify a standard for the Internet community.           
  2585.  
  2586. Extensions to FTP (ftpext)
  2587. --------------------------
  2588.  
  2589.   "Extended Directory Listing and Restart Mechanism for FTP", Robert Elz, 
  2590.   Paul Hethmon, 08/01/1997, <draft-ietf-ftpext-mlst-02.txt>                
  2591.  
  2592.        In order to overcome the problems caused by the undefined format of
  2593.        the current FTP LIST command output, a new command is needed to
  2594.        transfer standardized listing information from Server-FTP to Client-
  2595.        FTP.  Commands to enable this are defined in this document.
  2596.      
  2597.        This proposal also extends the FTP protocol to allow character sets
  2598.        other than US-ASCII[1] by allowing the transmission of 8-bit
  2599.        characters and the recommended use of UTF-8[2] encoding.
  2600.      
  2601.        Much implemented, but long undocumented, mechanisms to permit
  2602.        restarts of interrupted data transfers in STREAM mode, are also
  2603.        included here.
  2604.     
  2605.        This version contains corrections and additions agreed on the 
  2606.     mailing
  2607.        list.  Some sections incomplete in the previous draft have been
  2608.        completed.  Several editorial adjustments have been made.  This
  2609.        version is still not nearly complete.  This paragraph will be 
  2610.     deleted
  2611.        from the final version of this document.
  2612.                                                                            
  2613.  
  2614.   "Internationalization of the File Transfer Protocol", B. Curtin, 
  2615.   06/11/1997, <draft-ietf-ftpext-intl-ftp-02.txt>                          
  2616.  
  2617.     The File Transfer Protocol, as defined in RFC 959 [RFC959] and RFC 1123
  2618.     Section 4 [RFC1123], is one of the oldest and widely used protocols on 
  2619.     the Internet. The protocol's primary character set, 7 bit ASCII, has 
  2620.     served the protocol well through the early growth years of the 
  2621.     Internet. However, as the Internet becomes more global, there is a need
  2622.     to support character sets beyond 7 bit ASCII.                          
  2623.     This document addresses the internationalization (I18n) of FTP, which 
  2624.     includes supporting the multiple character sets found throughout the 
  2625.     Internet community.  This is achieved  by extending the FTP 
  2626.     specification and giving recommendations for proper 
  2627.     internationalization support.                                          
  2628.  
  2629.   "REST Command and Extensions to FTP", R. Adams, David Borman, 03/21/1997,
  2630.   <draft-ietf-ftpext-restart-00.txt>                                       
  2631.  
  2632.     This memo describes changes to FTP [1], which were proposed by Rick 
  2633.     Adams in May of 1989, to allow the RESTART mechanism to be used with 
  2634.     STREAM mode transfers.  Along with this, two new optional commands are 
  2635.     added, MODIFICATION TIME (MDTM) and SIZE OF FILE (SIZE).  All these 
  2636.     changes have been implemented, and are in use today in many production 
  2637.     FTP implementations.                                                   
  2638.  
  2639.   "Feature negotiation mechanism for the File Transfer Protocol", Robert 
  2640.   Elz, Paul Hethmon, 07/28/1997, <draft-ietf-ftpext-feat-01.txt>           
  2641.  
  2642.     The File Transfer Protocol is, from time to time, extended with new 
  2643.     commands, or facilities.  Implementations of the FTP protocol cannot be
  2644.     assumed to all immediately implement all newly defined mechanisms.  
  2645.     This document provides a mechanism by which clients of the FTP protocol
  2646.     can discover which new features are supported by a particular FTP 
  2647.     server.      A new security considerations section has been added.  One
  2648.     previously legal way to indicate no features has been deleted.  The 
  2649.     usual kinds of editorial updates have been made.                       
  2650.  
  2651. G and R for Security Incident Processing (grip)
  2652. -----------------------------------------------
  2653.  
  2654.   "Expectations for Computer Security Incident Response", Nevil Brownlee, 
  2655.   Erik Guttman, 09/29/1997, <draft-ietf-grip-framework-irt-08.txt>         
  2656.  
  2657.        The purpose of this document is to express the general Internet
  2658.        community's expectations of Computer Security Incident Response
  2659.        Teams (CSIRTs). It is not possible to define a set of requirements
  2660.        that would be appropriate for all teams, but it is possible and
  2661.        helpful to list and describe the general set of topics and issues
  2662.        which are of concern and interest to constituent communities.
  2663.     
  2664.        CSIRT constituents have a legitimate need and right to fully
  2665.        understand the policies and procedures of 'their' Computer Security
  2666.        Incident Response Team.  One way to support this understanding is to
  2667.        supply detailed information which users may consider, in the form of
  2668.        a formal template completed by the CSIRT.  An outline of such a
  2669.        template and a filled in example are provided.                      
  2670.  
  2671.   "Security Expectations for Internet Service Providers", Tom Killalea, 
  2672.   10/21/1997, <draft-ietf-grip-isp-00.txt>                                 
  2673.  
  2674.        The purpose of this document is to express the general Internet
  2675.        community's expectations of Internet Service Providers (ISPs) with
  2676.        respect to security.
  2677.      
  2678.        It is not the intent of this document to define a set of
  2679.        requirements that would be appropriate for all ISPs, but rather to
  2680.        raise awareness among ISPs of the community's expectations, and to
  2681.        provide the community with a framework for discussion of security
  2682.        expectations with current and prospective service providers.        
  2683.  
  2684. HyperText Transfer Protocol (http)
  2685. ----------------------------------
  2686.  
  2687.   "PEP - an Extension Mechanism for HTTP", D. Connolly, H. Nielsen, R. 
  2688.   Khare, 07/15/1997, <draft-ietf-http-pep-04.txt, .ps>                     
  2689.  
  2690.     HTTP is used increasingly in applications that need more facilities 
  2691.     than the standard version of the protocol provides, ranging from 
  2692.     distributed authoring, collaboration, and printing, to various remote 
  2693.     procedure call mechanisms. The Protocol Extension Protocol (PEP) is an 
  2694.     extension mechanism designed to address the tension between private 
  2695.     agreement and public specification and to accommodate extension of 
  2696.     applications such as HTTP clients, servers, and proxies. The PEP 
  2697.     mechanism is designed to associate each extension with a URI[2], and 
  2698.     use a few new RFC 822[1] derived header fields to carry the extension 
  2699.     identifier and related information between the parties involved in an 
  2700.     extended transaction.                                                  
  2701.  
  2702.   "Transparent Content Negotiation in HTTP", K. Holtman, A. Mutz, 
  2703.   09/15/1997, <draft-ietf-http-negotiation-04.txt>                         
  2704.  
  2705.             HTTP allows web site authors to put multiple versions of the
  2706.             same information under a single URL.  Transparent content
  2707.             negotiation is an extensible negotiation mechanism, layered on
  2708.             top of HTTP, for automatically selecting the best version when
  2709.             the URL is accessed.  This enables the smooth deployment of
  2710.             new web data formats and markup tags.
  2711.     
  2712.                                                                            
  2713.  
  2714.   "Feature Tag Registration Procedures", K. Holtman, A. Mutz, 07/28/1997, 
  2715.   <draft-ietf-http-feature-reg-02.txt>                                     
  2716.  
  2717.     Recent Internet applications, such as the World Wide Web, tie together 
  2718.     a great diversity in data formats, client and server platforms, and 
  2719.     communities.  This has created a need for various kinds of negotiation 
  2720.     mechanisms, which tailor the data which is exchanged, or the exchange 
  2721.     process, to the capabilities and preferences of the parties involved.  
  2722.     Extensible negotiation mechanisms need a vocabulary to identify various
  2723.     things which can be negotiated on.  To promote interoperability, a 
  2724.     registration process is needed to ensure that that this vocabulary, 
  2725.     which can be shared between negotiation mechanisms, is developed in an 
  2726.     orderly, well-specified, and public manner.                            
  2727.     This document defines registration procedures which use the Internet 
  2728.     Assigned Numbers Authority (IANA) as a central registry for this 
  2729.     vocabulary, which is the vocabulary of feature tags.                   
  2730.  
  2731.   "HTTP Remote Variant Selection Algorithm -- RVSA/1.0", K. Holtman, A. 
  2732.   Mutz, 07/28/1997, <draft-ietf-http-rvsa-v10-02.txt>                      
  2733.  
  2734.     HTTP allows web site authors to put multiple versions of the same 
  2735.     information under a single URL.  Transparent content negotiation is a 
  2736.     mechanism for automatically selecting the best version when the URL is 
  2737.     accessed.  A remote variant selection algorithm can be used to speed up
  2738.     the transparent negotiation process. This document defines the remote 
  2739.     variant selection algorithm with the version number 1.0.               
  2740.  
  2741.   "Problem with HTTP/1.1 Warning header, and proposed fix", Jeff Mogul, Ari
  2742.   Luotonen, 07/30/1997, <draft-ietf-http-warning-00.txt>                   
  2743.  
  2744.            The current HTTP/1.1 (RFC2068) specification introduces a
  2745.             new Warning header, meant to carry status information
  2746.             about a request that cannot or should not be carried by the
  2747.             response status code.  The existing specification for the
  2748.             interaction between Warning and HTTP caches is faulty, in
  2749.             that it may allow incorrect results after cache validation
  2750.             operations.  This document identifies two separate (but
  2751.             related) problems, and proposes revisions of the HTTP/1.1
  2752.             specification to solve these problems.
  2753.                                                                            
  2754.  
  2755.   "HTTP State Management Mechanism (Rev1)", D. Kristol, L. Montulli, 
  2756.   10/27/1997, <draft-ietf-http-state-man-mec-04.txt,.ps>                   
  2757.  
  2758.     This document specifies a way to create a stateful session with HTTP
  2759.     requests and responses.  It describes two new headers, Cookie and Set-
  2760.     Cookie2, which carry state information between participating origin
  2761.     servers and user agents.  The method described here differs from
  2762.     Netscape's Cookie proposal, but it can interoperate with HTTP/1.0 user
  2763.     agents that use Netscape's method.  (See the HISTORICAL section.)
  2764.     
  2765.     This document reflects implementation experience with RFC 2109 and
  2766.     obsoletes it.                                                          
  2767.  
  2768.   "The User Agent Hint Response Header", D. Morris, 09/16/1997, 
  2769.   <draft-ietf-http-uahint-01.txt>                                          
  2770.  
  2771.        This document proposes a HTTP response header called UA-Hint, which
  2772.        can be used by applications (servers) to describe handling hints
  2773.        which will allow user agents to more accurately reflect the intent 
  2774.     of
  2775.        the web application designer for the handling and presentation of 
  2776.     the
  2777.        response entity.  The UA-Hint header is intended to be an extensible
  2778.        general mechanism by which the application can suggest user agent
  2779.        behaviors which alter or extend the behaviors specified in HTTP/1.1
  2780.        (RFC 2068) with the express purpose of improving the usability of 
  2781.     the
  2782.        resulting application.  Intended considerations include enablement 
  2783.     of
  2784.        a safe POST and refined handling of the traditional history buffer. 
  2785.  
  2786.   "HTTP Connection Management", A. Freier, J. Gettys, 03/26/1997, 
  2787.   <draft-ietf-http-connection-00.txt>                                      
  2788.  
  2789.     The HTTP/1.1 specification (RFC 2068) is silent about various details 
  2790.     of TCP connection management when using persistent connections.  This 
  2791.     document discusses some of the implementation issues discussed during 
  2792.     HTTP/1.1's design, and introduces a few new requirements on HTTP/1.1 
  2793.     implementations learned from implementation experience, not fully 
  2794.     understood when RFC 2068 was issued.  This is an initial draft for 
  2795.     working group comment, and we expect further drafts.                   
  2796.  
  2797.   "HTTP Trust Mechanism for State Management", D. Jaye, 10/27/1997, 
  2798.   <draft-ietf-http-jaye-trust-state-01.txt>                                
  2799.  
  2800.     This document specifies an addition to the state management protocol
  2801.     specified in draft-ietf-http-state-man-mec-03[Kristol].  The intent is
  2802.     to provide a mechanism that allows user agents to determine the privacy
  2803.     practices of a server and to accept or reject cookies based on those
  2804.     practices.  Allowing the user to establish preferences for how to 
  2805.     handle
  2806.     cookies based on the server's practices provides a practical mechanism 
  2807.     to provide users control over the privacy implications of cookies.
  2808.      
  2809.     To provide verification of server privacy practices, we assume the
  2810.     existence of one or more independent Trust Authorities.  The authority
  2811.     establishes PICS ratings representing server privacy practices. It then
  2812.     issues trust-labels, in the form of digitally signed PICS labels, to
  2813.     organizations for specific domains and paths based on the server 
  2814.     privacy
  2815.     practices.  The Trust Authority must be able to audit domains to
  2816.     verify their adherence to a given level.  Passing these trust-labels
  2817.     along with cookies allows the user agent to support cookie handling 
  2818.     preferences based on trusted privacy practices.
  2819.      
  2820.     This document describes how PICS-headers are used in conjunction with
  2821.     Set-Cookie or Set-Cookie2 headers in [Kristol] to provide trust-labels
  2822.     to communicate the privacy practices of servers regarding cookies.     
  2823.  
  2824.   "Scenarios for the Delivery of Negotiated Content using HTTP", E. Hardie,
  2825.   07/15/1997, <draft-ietf-http-negotiate-scenario-01.txt>                  
  2826.  
  2827.     This document describes various problems which have arisen in attempts 
  2828.     to deliver negotiated content using HTTP and examines several scenarios
  2829.     by which improvements in delivery might be accomplished.               
  2830.     This document does not discuss how HTTP might be used to negotiate the 
  2831.     use of other protocols to deliver content.                             
  2832.  
  2833.   "HTTP/1.1 305 and 306 Response Codes", Jeff Mogul, 06/16/1997, 
  2834.   <draft-cohen-http-305-306-responses-00.txt>                              
  2835.  
  2836.     The HTTP/1.1 RFC specifies a response code '305 Use Proxy' which is 
  2837.     intended to cause a client to retry the request using a specified proxy
  2838.     server.  This functionality is important, but underspecified in the 
  2839.     current spec.  The spec does not specify for how long or which URLs the
  2840.     redirect applies to, or how proxies can deal with or generate similar 
  2841.     responses.  This draft proposes a specification for both the 305 
  2842.     response and a new response, '306 Switch Proxy'.                       
  2843.  
  2844.   "Feature Tag Scenarios", K. Holtman, A. Mutz, 07/28/1997, 
  2845.   <draft-ietf-http-feature-scenarios-01.txt>                               
  2846.  
  2847.     Recent Internet applications, such as the World Wide Web, tie together 
  2848.     a great diversity in data formats, client and server platforms, and 
  2849.     communities.  This has created a need for various kinds of negotiation 
  2850.     mechanisms, which tailor the data which is exchanged, or the exchange 
  2851.     process itself, to the capabilities and preferences of the parties 
  2852.     involved.                                                              
  2853.     Extensible negotiation mechanisms need a vocabulary to identify various
  2854.     things which can be negotiated on.  To promote interoperability, a 
  2855.     registration process is needed to ensure that that this vocabulary, 
  2856.     which can be shared between negotiation mechanisms, is developed in an 
  2857.     orderly, well-specified, and public manner.                            
  2858.     This document discusses requirements and scenarios the registration of 
  2859.     this vocabulary, which is the vocabulary of feature tags.  Feature tag 
  2860.     registration is foreseen as an ongoing, open process which will keep 
  2861.     pace with the introduction of new features by software vendors, and 
  2862.     other parties such as standards bodies.                                
  2863.  
  2864.   "An Extension to HTTP : Digest Access Authentication", J. Franks, A. 
  2865.   Luotonen, P. Leach, J. Hostetler, P. Hallam-Baker, 07/30/1997, 
  2866.   <draft-ietf-http-digest-aa-rev-00.txt>                                   
  2867.  
  2868.     The protocol referred to as 'HTTP/1.0' includes the specification for
  2869.        a Basic Access Authentication scheme.  This scheme is not considered
  2870.        to be a secure method of user authentication, as the user name and
  2871.        password are passed over the network as clear text.  A specification
  2872.        for a different authentication scheme is needed to address this
  2873.        severe limitation.  This document provides specification for such a
  2874.        scheme, referred to as 'Digest Access Authentication'.  Like Basic,
  2875.        Digest access authentication verifies that both parties to a
  2876.        communication know a shared secret (a password); unlike Basic, this
  2877.        verification can be done without sending the password in the clear,
  2878.        which is Basic's biggest weakness. As with most other authentication
  2879.        protocols, the greatest sources of risks are usually found not in 
  2880.     the
  2881.        core protocol itself but in policies and procedures surrounding its
  2882.        use. 
  2883.     
  2884.        This is the final draft of any document under this name.  Digest and
  2885.        Basic Authentication from the HTTP/1.1 specification will be 
  2886.     combined
  2887.        and issued as a document titled 'Authentication in HTTP'.Our intent
  2888.        is that RFC 2068 and RFC 2069 will go to draft standard as a pair of
  2889.        documents, but with all authentication schemes (Digest and Basic)
  2890.        documented together in a single place.  This transition has not yet
  2891.        taken place.                                                        
  2892.  
  2893.   "Specification of HTTP/1.1 OPTIONS messages", J Mogul, S Lawrence, J 
  2894.   Cohen, 08/29/1997, <draft-ietf-http-options-02.txt>                      
  2895.  
  2896.             RFC2068 defined a new OPTIONS method for HTTP/1.1.  The
  2897.             purpose of OPTIONS is to allow a 'client to determine the
  2898.             options and/or requirements associated with a resource, or
  2899.             the capabilities of a server, without implying a resource
  2900.             action or initiating a resource retrieval.'  However,
  2901.             RFC2068 did not defined a specific syntax for using OPTIONS
  2902.             to make such a determination.  This proposal clarifies the
  2903.             original specification of OPTIONS, adds several new HTTP
  2904.             message headers to provide syntactic support for OPTIONS,
  2905.             and establishes new IANA registries to avoid namespace
  2906.             conflicts.                                                     
  2907.  
  2908.   "The Alternates Header Field", K. Holtman, A. Mutz, 09/15/1997, 
  2909.   <draft-ietf-http-alternates-00.txt>                                      
  2910.  
  2911.             HTTP allows web site authors to put multiple versions of the
  2912.             same information under a single URL.  The Alternates header
  2913.             field can be used to transmit a machine-readable description
  2914.             of these versions.  This allows the recipient to automatically
  2915.             select the most appropriate version.                           
  2916.  
  2917.   "Format and Example of HTTP/1.1 Requirements Summary", J Mogul, 
  2918.   09/15/1997, <draft-ietf-http-req-sum-00.txt>                             
  2919.  
  2920.             RFC1122 [1] introduced a ``Requirements Summary'' format,
  2921.             to help implementors understand what aspects of a lengthy
  2922.             specification were mandatory, recommended, or optional.
  2923.             The HTTP/1.1 specification is similarly lengthy and
  2924.             complicated; many implementors have asked for guidance in
  2925.             understanding what they need to do.  The latest draft
  2926.             revision of the HTTP/1.1 specification [2] has a
  2927.             placeholder section for a ``Requirements Summary'', but
  2928.             there has been relatively little discussion of the format
  2929.             and content of this summary in the HTTP working group.
  2930.             This document proposes a specific format for the summary,
  2931.             and gives an example summary for one section of the
  2932.             document.
  2933.                                                                            
  2934.  
  2935.   "Hypertext Transfer Protocol -- HTTP/1.1", J Mogul, Tim Berners-Lee, R. 
  2936.   Fielding, H. Nielsen, J. Gettys, 10/16/1997, 
  2937.   <draft-ietf-http-v11-spec-rev-00.txt,.ps>                                
  2938.  
  2939.     The Hypertext Transfer Protocol (HTTP) is an application-
  2940.                 level protocol for distributed, collaborative, hypermedia
  2941.                 information systems. It is a generic, stateless, object-
  2942.                 oriented protocol which can be used for many tasks, such as
  2943.                 name servers and distributed object management systems,
  2944.                 through extension of its request methods. A feature of HTTP
  2945.                 is the typing and negotiation of data representation,
  2946.                 allowing systems to be built independently of the data 
  2947.     being
  2948.                 transferred.                                               
  2949.  
  2950. IEEE 802.3 Hub MIB (hubmib)
  2951. ---------------------------
  2952.  
  2953.   "Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units 
  2954.   (MAUs) using SMIv2", Keith McCloghrie, Donna McMaster, Dan Romascanu, S. 
  2955.   Roberts, K. De Graaf, 03/03/1997, <draft-ietf-hubmib-mau-mib-04.txt>     
  2956.  
  2957.     This memo defines an experimental portion of the Management Information
  2958.     Base (MIB) for use with network management protocols in the Internet 
  2959.     community.  In particular, it defines objects for managing 10 and 100 
  2960.     Mb/second Medium Attachment Units (MAUs) based on IEEE Std 802.3 
  2961.     Section 30, '10 & 100 Mb/s Management,' October 26, 1995.              
  2962.     This memo does not specify a standard for the Internet community.      
  2963.  
  2964. Internet Architecture Board (iab)
  2965. ---------------------------------
  2966.  
  2967.   "Improved Working Group Coordination", Brian Carpenter, 10/29/1997, 
  2968.   <draft-iab-wgannounce-00.txt>                                            
  2969.  
  2970.        This is a proposal for a pragmatic way to improve working group
  2971.        coordination between various standards-related organisations, by use
  2972.        of a shared mailing list for early announcement of new activities.  
  2973.  
  2974. Inter-Domain Multicast Routing (idmr)
  2975. -------------------------------------
  2976.  
  2977.   "Protocol Independent Multicast MIB", Keith McCloghrie, D. Farinacci, D. 
  2978.   Thaler, 03/26/1997, <draft-ietf-idmr-pim-mib-03.txt>                     
  2979.  
  2980.     This memo defines an experimental portion of the Management Information
  2981.     Base (MIB) for use with network management protocols in the Internet 
  2982.     community.  In particular, it describes managed objects used for 
  2983.     managing the Protocol Independent Multicast (PIM) protocol [5,6,7,8].  
  2984.     This MIB module is applicable to IP multicast routers which implement 
  2985.     PIM.                                                                   
  2986.  
  2987.   "Internet Group Management Protocol MIB", Keith McCloghrie, D. Farinacci,
  2988.   D. Thaler, 07/21/1997, <draft-ietf-idmr-igmp-mib-05.txt>                 
  2989.  
  2990.     This memo defines an experimental portion of the Management Information
  2991.     Base (MIB) for use with network management protocols in the Internet 
  2992.     community.  In particular, it describes managed objects used for 
  2993.     managing the Internet Group Management Protocol (IGMP).  All of this 
  2994.     MIB module is applicable to IP multicast routers [6,7,8,9,10]; a subset
  2995.     is applicable to hosts implementing IGMPv1 [5] or IGMPv2 [11].         
  2996.  
  2997.   "IP Multicast Routing MIB", Keith McCloghrie, D. Farinacci, D. Thaler, 
  2998.   03/26/1997, <draft-ietf-idmr-multicast-routmib-05.txt>                   
  2999.  
  3000.     This memo defines an experimental portion of the Management Information
  3001.     Base (MIB) for use with network management protocols in the Internet 
  3002.     community.  In particular, it describes managed objects used for 
  3003.     managing IP Multicast Routing [5], independent of the specific 
  3004.     multicast routing protocol [6,7,8,9,10] in use.  Managed objects 
  3005.     specific to particular multicast routing protocols are specified 
  3006.     elsewhere.                                                             
  3007.  
  3008.   "Internet Group Management Protocol, Version 2", Bill Fenner, 10/30/1997,
  3009.   <draft-ietf-idmr-igmp-v2-07.txt>                                         
  3010.  
  3011.     This draft documents IGMPv2, used by IP hosts to report their
  3012.          multicast group memberships to routers.  It replaces Appendix I of
  3013.          RFC1112.
  3014.      
  3015.          IGMPv2 allows group membership termination to be quickly reported
  3016.          to the routing protocol, which is important for high-bandwidth
  3017.          multicast groups and/or subnets with highly volatile group
  3018.          membership.
  3019.      
  3020.     This document is a product of the Inter-Domain Multicast Routing 
  3021.     working
  3022.     group within the Internet Engineering Task Force.  Comments are
  3023.     solicited and should be addressed to the working group's mailing list 
  3024.     at
  3025.     idmr@cs.ucl.ac.uk and/or the author(s).                                
  3026.  
  3027.   "Protocol Independent Multicast Version 2, Dense Mode Specification", V. 
  3028.   Jacobson, D. Farinacci, L. Wei, Steve Deering, A. Helmy, 05/28/1997, 
  3029.   <draft-ietf-idmr-pim-dm-spec-05.txt>                                     
  3030.  
  3031.     This specification defines a multicast routing algorithm for multicast 
  3032.     groups that are densely distributed across an internet. The protocol is
  3033.     unicast routing protocol independent. It is based on the PIM 
  3034.     sparse-mode [PIMSM] and employs the same packet formats. This protocol 
  3035.     is called dense-mode PIM. The foundation of this design was largely 
  3036.     built on [Deering91].                                                  
  3037.  
  3038.   "Distance Vector Multicast Routing Protocol", T. Pusateri, 10/30/1997, 
  3039.   <draft-ietf-idmr-dvmrp-v3-05.txt,.ps>                                    
  3040.  
  3041.        DVMRP is an Internet routing protocol that provides an efficient
  3042.        mechanism for connection-less datagram delivery to a group of hosts
  3043.        across an internetwork. It is a distributed protocol that 
  3044.     dynamically
  3045.        generates IP Multicast delivery trees using a technique called
  3046.        Reverse Path Multicasting (RPM) [Deer90]. This document is an update
  3047.        to Version 1 of the protocol specified in RFC 1075 [Wait88].5       
  3048.  
  3049.   "Core Based Tree (CBT) Multicast Border Router Specification", Tony 
  3050.   Ballardie, 10/27/1997, <draft-ietf-idmr-cbt-br-spec-00.txt>              
  3051.  
  3052.        This document specifies the behaviour of a CBT multicast border
  3053.        router (BR) attaching a CBT multicast domain/region (stub or 
  3054.     transit)
  3055.        to an inter-domain multicast tree, which may be source-rooted or
  3056.        shared.
  3057.     
  3058.        This draft assumes a CBT domain's multicast border routers have im-
  3059.        plemented Multicast BGP such that they can maintain ''come from'' 
  3060.     (mul-
  3061.        ticast) paths that reflect local multicast policy. These may be 
  3062.     inde-
  3063.        pendent of unicast (''go to'') paths and policy. Provision for this 
  3064.     ca-
  3065.        pability in BGP is described in [1].
  3066.      
  3067.        The document provides guidelines that are intended to be generally
  3068.        aligned with the mechanisms described in the ''Interoperability 
  3069.     Rules
  3070.        for Multicast Routing Protocols'' [3]. Certain aspects of those 
  3071.     rules
  3072.        may be interpreted and implemented differently, and therefore some
  3073.        discretion is left to the implementor.                              
  3074.  
  3075.   "Core Based Trees (CBT) Multicast Routing MIB", Tony Ballardie, D. 
  3076.   Thaler, 07/21/1997, <draft-ietf-idmr-cbt-mib-00.txt>                     
  3077.  
  3078.     This memo defines an experimental portion of the Management Information
  3079.     Base (MIB) for use with network management protocols in the Internet 
  3080.     community.  More precisely, it describes managed objects specific to 
  3081.     the Core Based Trees (CBT) multicast routing protocol version 2 [5]. 
  3082.     Managed objects which are common to all multicast routing protocols, 
  3083.     including CBT, can be found in [6].                                    
  3084.     This MIB module is applicable to IP multicast routers which implement 
  3085.     CBTv2.                                                                 
  3086.  
  3087.   "Border Gateway Multicast Protocol (BGMP): Protocol Specification", 
  3088.   Deborah Estrin, David Meyer, D. Thaler, 10/31/1997, 
  3089.   <draft-ietf-idmr-gum-01.txt>                                             
  3090.  
  3091.     This document describes BGMP, a protocol for inter-domain multicast
  3092.     routing. BGMP builds shared trees for active multicast groups, and
  3093.     allows receiver domains to build source-specific, inter-domain,
  3094.     distribution branches where needed. Building upon concepts from CBT and
  3095.     PIM-SM, BGMP requires that each multicast group be associated with a
  3096.     single root (in BGMP it is referred to as the root domain).  BGMP
  3097.     assumes that at any point in time, different ranges of the class D 
  3098.     space
  3099.     are associated (e.g., with MASC [MASC]) with different domains.  Each 
  3100.     of
  3101.     these domains then becomes the root of the shared domain-trees for all
  3102.     groups in its range.  Multicast participants will generally receive
  3103.     better multicast service if the session initiator's address allocator
  3104.     selects addresses from its own domain's part of the space, thereby
  3105.      causing the root domain to be local to at least one of the session
  3106.     participants.                                                          
  3107.  
  3108.   "Protocol  Independent  Multicast-Sparse   Mode   (PIM-SM):   Protocol 
  3109.   Specification", Deborah Estrin, D. Farinacci, Steve Deering, D. Thaler, 
  3110.   A. Helmy, 09/11/1997, <draft-ietf-idmr-pim-sm-specv2-00.txt,.ps>         
  3111.  
  3112.     This  document  describes  a  protocol  for  efficiently  routing  to
  3113.        multicast   groups   that   may  span  wide-area  (and  
  3114.     inter-domain)
  3115.        internets.                                                          
  3116.  
  3117. Inter-Domain Routing (idr)
  3118. --------------------------
  3119.  
  3120.   "A Border Gateway Protocol 4 (BGP-4)", Tony Li, Y Rekhter, 06/03/1997, 
  3121.   <draft-ietf-idr-bgp4-06.txt>                                             
  3122.  
  3123.     The Border Gateway Protocol (BGP) is an inter-Autonomous System routing
  3124.     protocol.  It is built on experience gained with EGP as defined in RFC 
  3125.     904 [1] and EGP usage in the NSFNET Backbone as described in RFC 1092 
  3126.     [2] and RFC 1093 [3].                                                  
  3127.  
  3128.   "Definitions of Managed Objects for the Fourth Version of Border Gateway 
  3129.   Protocol (BGP-4)", J. Burruss, Jodi Ito, Jeff Johnson, S. Willis, J. Chu,
  3130.   03/15/1996, <draft-ietf-idr-bgp4-mib-02.txt>                             
  3131.  
  3132.     This memo is an extension to the SNMP MIB.  It specifies an IAB 
  3133.     standards track protocol for the Internet community, and requests 
  3134.     discussion and suggestions for improvements.  The origin of this memo 
  3135.     is from RFC 1269 'Definitions of Managed Objects for the Board Gateway 
  3136.     Protocol (Version 3)' written by the first two authors of this memo, 
  3137.     which was updated to support BGP-4 in RFC 1657.  This memo fixes errors
  3138.     introduced when the MIB was converted to use the SNMPv2 SMI, as well as
  3139.     updates references to the Draft Standard SNMPv2 SMI documents.         
  3140.     Distribution of this memo is unlimited.  Please forward comments to 
  3141.     bgp@ans.net.                                                           
  3142.  
  3143.   "A Framework for Inter-Domain Route Aggregation", J. Stewart, E. Chen, 
  3144.   07/30/1997, <draft-ietf-idr-aggregation-framework-01.txt>                
  3145.  
  3146.     
  3147.        This document presents a framework for inter-domain route 
  3148.     aggregation
  3149.        and shows an example router configuration which 'implement' this
  3150.        framework.  This framework is flexible and scales well as it
  3151.        emphasizes the philosophy of aggregation by the source, both within
  3152.        routing domains as well as towards upstream providers, and it also
  3153.        strongly encourages the use of the 'no-export' BGP community to
  3154.        balance the provider-subscriber need for more granular routing
  3155.        information with the Internet's need for scalable inter-domain
  3156.        routing.
  3157.                                                                            
  3158.  
  3159.   "Using a Dedicated AS for Sites Homed to a Single Provider", E. Chen, T. 
  3160.   Bates, R. Chandra, John Stewart  III, 07/30/1997, 
  3161.   <draft-ietf-idr-as-dedicated-00.txt>                                     
  3162.  
  3163.        With the increased growth of the Internet, the number of customers
  3164.        using BGP4 has grown significantly. RFC1930 outlines a set of guide-
  3165.        lines for when one needs and should use an AS. However, the customer
  3166.        and service provider (ISP) are left with a problem as a result of
  3167.        this in that while there is no need for an allocated AS under the
  3168.        guidelines, certain conditions make the use of BGP4 a very pragmatic
  3169.        and perhaps only way to connect a customer homed to a single ISP.
  3170.        This paper proposes a solution to this problem in line with 
  3171.     recommen-
  3172.        dations set forth in RFC1930.
  3173.                                                                            
  3174.  
  3175.   "Route Aggregation Tutorial", E. Chen, John Stewart  III, 07/30/1997, 
  3176.   <draft-ietf-idr-aggregation-tutorial-00.txt>                             
  3177.  
  3178.        Route aggregation is critical to the long-term viability of the
  3179.        Internet.  This document presents practical information that network
  3180.        managers can use to both understand the concepts of aggregation as
  3181.        well as put those concepts into use in order to do their part to 
  3182.     make
  3183.        the Internet stable and allow its continued growth.  The intended
  3184.        audience for this document is anyone responsible for configuring a
  3185.        network which has its own Autonomous System Number (ASN) and
  3186.        exchanges routing information with its Internet Service Provider(s)
  3187.        (ISP(s)) using the Border Gateway Protocol (BGP).  This document 
  3188.     does
  3189.        not cover multi-homing, though multi-homed sites can still benefit
  3190.        from understanding this material.                                   
  3191.  
  3192.   "Multiprotocol Extensions for BGP-4", D Katz, Y Rekhter, T. Bates, R. 
  3193.   Chandra, 09/26/1997, <draft-ietf-idr-bgp4-multiprotocol-01.txt>          
  3194.  
  3195.        Currently BGP-4 [BGP-4] is capable of carrying routing information
  3196.        only for IPv4 [IPv4]. This document defines extensions to BGP-4 to
  3197.        enable it to carry routing information for multiple Network Layer
  3198.        protocols (e.g., IPv6, IPX, etc...). The extensions are backward
  3199.        compatible - a router that supports the extensions can interoperate
  3200.        with a router that doesn't support the extensions.
  3201.                                                                            
  3202.  
  3203.   "Capabilities Negotiation with BGP-4", J. Scudder, R. Chandra, 
  3204.   09/09/1997, <draft-ietf-idr-bgp4-cap-neg-00.txt>                         
  3205.  
  3206.        Currently BGP-4 [BGP-4] requires that when a BGP speaker receives an
  3207.        OPEN message with one or more unrecognized Optional Parameters, the
  3208.        speaker must terminate BGP peering. This complicates introduction of
  3209.        new capabilities in BGP.
  3210.          
  3211.        This document defines new Optional Parameter, called Capabilities,
  3212.        that is expected to facilitate introduction of new capabilities in
  3213.        BGP by providing graceful capability negotiation.
  3214.          
  3215.        The proposed parameter is backward compatible - a router that
  3216.        supports the parameter can maintain BGP peering with a router that
  3217.        doesn't support the parameter.
  3218.                                                                            
  3219.  
  3220. Integrated Directory Services (ids)
  3221. -----------------------------------
  3222.  
  3223.   "Introducing a Directory Service", Erik Huizer, T. Verschuren, P. Jurg, 
  3224.   E. Jeunink, M. Jacobs, 10/17/1995, <draft-ietf-ids-x500-intro-dir-00.txt>
  3225.  
  3226.     This report provides a 'manual' for establishing an electronic White 
  3227.     Pages Directory Service within an organisation and for connecting it to
  3228.     a wide-area Directory infrastructure. It is based on the experiences 
  3229.     from the SURFnet Directory Services pilot project. The wide-area 
  3230.     service is of importance to all users of e-mail services who want to 
  3231.     find e-mail addresses of other e-mail users (worldwide!) or any other 
  3232.     address information such as telephone and fax numbers.     Establishing
  3233.     a White Pages Directory Service within an organisation includes a 
  3234.     technical, legal and data management component. As the amount of work 
  3235.     involved in the technical component can be reduced by using standard 
  3236.     equipment and by good support from the provider of the wide-area 
  3237.     Directory infrastructure, the legal and data management issues require 
  3238.     more attention. Legal aspects include formal registration of the 
  3239.     service, informing all registered persons about the service and data 
  3240.     protection.                                                            
  3241.  
  3242.   "The CCSO Nameserver (Ph) Architecture", P. Pomes, Roland Hedberg, 
  3243.   05/06/1997, <draft-ietf-ids-ph-03.txt>                                   
  3244.  
  3245.     The PH Nameserver from the [Computing and Communications Services 
  3246.     Office (CCSO),] University of Illinois at Urbana-Champaign has for some
  3247.     time now been used by several organizations as their choice of publicly
  3248.     available database for information about people as well as other 
  3249.     things.  It is now widely felt that the Internet community would 
  3250.     benefit from having a more rigorous definition of the client-server 
  3251.     protocol, this document will hopefully achieve that goal.  The Ph 
  3252.     service as specified in this document is built around an information 
  3253.     model, a client command language and the server responses.             
  3254.  
  3255.   "Best Current Practice for the Internet White Pages Service", Harald 
  3256.   Alvestrand, P. Jurg, 04/30/1997, <draft-ietf-ids-ds-bcp-04.txt>          
  3257.  
  3258.     The Internet is used for information exchange and communication between
  3259.     its users. It can only be effective as such if users are able to find 
  3260.     each other's addresses. Therefore the Internet benefits from an 
  3261.     adequate White Pages Service, i.e., a directory service offering 
  3262.     (Internet) address information related to people and organizations.    
  3263.  
  3264.   "Simple Nomenclator Query Protocol (SNQP)", J. Ordille, J. Elliott, 
  3265.   08/04/1997, <draft-ietf-ids-snqp-01.txt>                                 
  3266.  
  3267.        The Simple Nomenclator Query Protocol (SNQP) allows a client to
  3268.        communicate with a descriptive name service or other 
  3269.     relational-style
  3270.        query service.  The protocol is useful to services that search many
  3271.        data repositories for query responses.  Clients can pose queries on
  3272.        relations, list descriptions of relations, and obtain advice on
  3273.        reducing the search time and cost of their queries.  Clients are
  3274.        informed of the age of information in caches, and may request more
  3275.        recent information.  SNQP provides support for graphical user
  3276.        interfaces.  It also supports different types of comparison
  3277.        operators, so services can use SNQP with a variety of back-end
  3278.        servers, e.g. relational database servers, CCSO servers, and servers
  3279.        providing relational views of X.500.
  3280.      
  3281.        SNQP is an ASCII protocol in the request-reply style of SMTP.  It 
  3282.     was
  3283.        specifically designed for use with the Nomenclator name and
  3284.        information service, and has been useful elsewhere.                 
  3285.  
  3286.   "Internet Nomenclator Project", J. Ordille, 08/06/1997, 
  3287.   <draft-ietf-ids-inp-02.txt>                                              
  3288.  
  3289.          The goal of the Internet Nomenclator Project is to integrate the
  3290.         hundreds of publicly available CCSO servers from around the world.
  3291.         Each CCSO server has a database schema that is tailored to the 
  3292.     needs
  3293.         of the organization that owns it.  The project is integrating the
  3294.         different database schema into one query service.  The Internet
  3295.         Nomenclator Project will provide fast cross-server searches for
  3296.         locating people on the Internet.  It augments existing CCSO 
  3297.     services
  3298.         by supplying schema integration, more extensive indexing, and two
  3299.         kinds of caching -- all this in a system that scales as the number
  3300.         of CCSO servers grows.  One of the best things about the system is
  3301.         that administrators can incorporate their CCSO servers into
  3302.         Nomenclator without changing the servers. All Nomenclator needs is
  3303.         basic information about the server.
  3304.      
  3305.         This document provides an overview of the Nomenclator system,
  3306.         describes how to register a CCSO server in the Internet Nomenclator
  3307.         Project, and how to use the Nomenclator search engine to find 
  3308.     people
  3309.         on the Internet.
  3310.      
  3311.         Distribution of this document is unlimited.  Comments should be 
  3312.     sent
  3313.         to the author.                                                     
  3314.  
  3315.   "Naming Plan for Internet Directory-Enabled Applications", Steve Kille, 
  3316.   Rick Huber, Sri Sataluri, A. Grimstad, M. Wahl, 09/10/1997, 
  3317.   <draft-ietf-ids-dirnaming-02.txt>                                        
  3318.  
  3319.     Application of the conventional X.500 approach to naming has
  3320.        heretofore, in the experience of the authors, proven to be an
  3321.        obstacle to the wide deployment of directory-enabled applications on
  3322.        the Internet.  We propose a new directory naming plan that leverages
  3323.        the strengths of the most popular and successful Internet naming
  3324.        schemes for naming objects in a hierarchical directory.  This plan
  3325.        can, we believe, facilitate the creation of an Internet White Pages
  3326.        Service (IWPS) and other directory-enabled applications by 
  3327.     overcoming
  3328.        the problems encountered by those using the conventional X.500
  3329.        approach to naming.                                                 
  3330.  
  3331. IETF Steering Group (iesg)
  3332. --------------------------
  3333.  
  3334.   "Guidelines for Writing an IANA Considerations Section in RFCs", Harald 
  3335.   Alvestrand, Thomas Narten, 10/06/1997, 
  3336.   <draft-iesg-iana-considerations-00.txt>                                  
  3337.  
  3338.        Many protocols make use of identifiers consisting of constants and
  3339.        other well-known values. Even after a protocol has been defined and
  3340.        deployment has begun, new values may need to be assigned (e.g., a 
  3341.     new
  3342.        option type in DHCP).  To insure that such quantities have unique
  3343.        values, their assignment must be administered by a central 
  3344.     authority.
  3345.        In the Internet, that role is provided by the Internet Assigned
  3346.        Numbers Authority (IANA).
  3347.      
  3348.        In order for the IANA to manage a given numbering space prudently, 
  3349.     it
  3350.        needs guidelines describing the conditions under which new values 
  3351.     can
  3352.        be assigned. If the IANA is expected to play a role in the 
  3353.     management
  3354.        of a numbering space, the IANA must be given clear and concise      
  3355.     guidelines describing that role.  This document discusses issues that
  3356.        should be considered in formulating an identifier assignment policy
  3357.        and provides guidelines to document authors on the specific text 
  3358.     that
  3359.        must be included in documents that place demands on the IANA.       
  3360.  
  3361.   "MIB Interoperability Testing", Michael O'Dell, 10/27/1997, 
  3362.   <draft-iesg-odell-mibtest-00.txt>                                        
  3363.  
  3364.     This document specifies the IESG's interpretation of the Internet
  3365.        Standards Process for the progression of SNMP MIB specifications to
  3366.        the Draft Standard level of maturity.  It discusses the rationale 
  3367.     for
  3368.        this interpretation and details the testing which is used to satisfy
  3369.        the advancement criteria.                                           
  3370.  
  3371. Interfaces MIB (ifmib)
  3372. ----------------------
  3373.  
  3374.   "The Interfaces Group MIB", Frank Kastenholz, Keith McCloghrie, 
  3375.   10/19/1997, <draft-ietf-ifmib-mib-06.txt>                                
  3376.  
  3377.     This memo defines a portion of the Management Information Base
  3378.     (MIB) for use with network management protocols in the Internet
  3379.     community.  In particular, it describes managed objects used for
  3380.     managing Network Interfaces.
  3381.     
  3382.     This memo discusses the 'interfaces' group of MIB-II, especially
  3383.     the experience gained from the definition of numerous media-
  3384.     specific MIB modules for use in conjunction with the 'interfaces'
  3385.     group for managing various sub-layers beneath the internetwork-
  3386.     layer.  It specifies clarifications to, and extensions of, the
  3387.     architectural issues within the previous model used for the
  3388.     'interfaces' group.                                                    
  3389.  
  3390.   "Definitions of Managed Objects for System and Interface Testing", Keith 
  3391.   McCloghrie, Kaj Tesink, M. Greene, 06/09/1997, 
  3392.   <draft-ietf-ifmib-testmib-03.txt>                                        
  3393.  
  3394.     This memo defines an experimental portion of the Management Information
  3395.     Base (MIB) for use with network management protocols in the Internet 
  3396.     community.  In particular, it describes objects used for testing 
  3397.     systems and interfaces. This memo replaces the objects originally 
  3398.     defined in the ifTestGroup of RFC1573, the IF-MIB [6], which have been 
  3399.     deprecated.        This memo specifies a MIB module in a manner that is
  3400.     both compliant to the SNMPv2 SMI, and semantically identical to the 
  3401.     peer SNMPv1 definitions.     This memo does not specify a standard for 
  3402.     the Internet community.                                                
  3403.  
  3404. Integrated Services (intserv)
  3405. -----------------------------
  3406.  
  3407.   "A Measurement Based Admission Control Algorithm for Controlled-Load 
  3408.   Service with a Reference Implementation Framework", L. Breslau, S. Jamin,
  3409.   Cheng Jin, 10/09/1997, <draft-ietf-intserv-control-flow-01.txt>          
  3410.  
  3411.     Controlled-Load Service provides data flows with an enhanced quality
  3412.        of service, in the form of low packet delay and a low probability of
  3413.        packet loss even under congestion.  A network element providing
  3414.        Controlled-Load Service can use an admission control algorithm to
  3415.        limit the number of data flows receiving the service.  In this
  3416.        document we describe an admission control algorithm for Controlled-
  3417.        Load Service.  This algorithm is not intended for IETF    
  3418.     standardization.  Rather, it is presented for informational purposes
  3419.        only.
  3420.      
  3421.        We also present a reference implementation framework for the
  3422.        measurement-based admission control algorithm.  Our implementation
  3423.        separates the measurement from the actual admission control decision
  3424.        to provide the flexibility of using different algorithms in 
  3425.     bandwidth
  3426.        estimation and admission control.                                   
  3427.  
  3428.   "Integrated Services Management Information Base",, 10/13/1997, 
  3429.   <draft-ietf-intserv-v2-mib-00.txt>                                       
  3430.  
  3431.     This memo defines a portion of the Management Information Base
  3432.     (MIB) for use with network management protocols in TCP/IP-
  3433.     based internets.  In particular, it defines objects for
  3434.     managing the the interface attributes defined in the
  3435.     Integrated Services Model.  Comments should be made to the
  3436.     Integrated Services Working Group, int-serv@isi.edu.
  3437.      
  3438.     This memo does not, in its draft form, specify a standard for
  3439.     the Internet community.                                                
  3440.  
  3441. Internetworking Over NBMA (ion)
  3442. -------------------------------
  3443.  
  3444.   "Management Information Base for Frame Relay DTEs", Fred Baker, C. Brown,
  3445.   09/16/1997, <draft-ietf-iplpdn-frmib-dte-11.txt>                         
  3446.  
  3447.     This memo defines a portion of the Management Information Base (MIB) 
  3448.     for use with network management protocols in TCP/IP-based internets.  
  3449.     In particular, it defines objects for managing Frame Relay interfaces 
  3450.     on DTEs.                                                               
  3451.     This memo does not specify a standard for the Internet community.      
  3452.  
  3453.   "NBMA Next Hop Resolution Protocol (NHRP)", D Katz, David Piscitello, B. 
  3454.   Cole, J. Luciani, 10/30/1997, <draft-ietf-rolc-nhrp-12.txt>              
  3455.  
  3456.        This document describes the NBMA Next Hop Resolution Protocol 
  3457.     (NHRP).
  3458.        NHRP can be used by a source station (host or router) connected to a
  3459.        Non-Broadcast, Multi-Access (NBMA) subnetwork to determine the
  3460.        internetworking layer address and NBMA subnetwork addresses of the
  3461.        ''NBMA next hop'' towards a destination station.  If the destination
  3462.     is
  3463.        connected to the NBMA subnetwork, then the NBMA next hop is the
  3464.        destination station itself.  Otherwise, the NBMA next hop is the
  3465.        egress router from the NBMA subnetwork that is ''nearest'' to the
  3466.        destination station.  NHRP is intended for use in a multiprotocol 
  3467.     internetworking layer environment over NBMA subnetworks.
  3468.      
  3469.        Note that while this protocol was developed for use with NBMA
  3470.        subnetworks, it is possible, if not likely, that it will be applied
  3471.        to BMA subnetworks as well.  However, this usage of NHRP is for
  3472.        further study.  
  3473.     
  3474.        This document is intended to be a functional superset of the NBMA
  3475.        Address Resolution Protocol (NARP) documented in [1].
  3476.      
  3477.        Operation of NHRP as a means of establishing a transit path across 
  3478.     an
  3479.        NBMA subnetwork between two routers will be addressed in a separate
  3480.        document (see [13]).                                                
  3481.  
  3482.   "NHRP Protocol Applicability Statement", D. Cansever, 07/25/1997, 
  3483.   <draft-ietf-ion-nhrp-appl-02.txt>                                        
  3484.  
  3485.     As required by the Routing Protocol Criteria [RFC 1264], this draft 
  3486.     report discusses the applicability of the Next Hop Resolution Protocol 
  3487.     (NHRP) in routing of IP datagrams over Non-Broadcast Multiple Access 
  3488.     (NBMA) networks, such as ATM, SMDS and X.25. The final form of this 
  3489.     draft report is a prerequisite to advancing NHRP on the standards 
  3490.     track.                                                                 
  3491.  
  3492.   "Classical IP and ARP over ATM", Mark Laubach, Joel Halpern, 10/07/1997, 
  3493.   <draft-ietf-ion-ipatm-classic2-03.txt>                                   
  3494.  
  3495.     This memo defines an initial application of classical IP and ARP in
  3496.        an Asynchronous Transfer Mode (ATM) network environment configured 
  3497.     as
  3498.        a Logical IP Subnetwork (LIS) as described in Section 5.  This memo
  3499.        does not preclude the subsequent development of ATM technology into
  3500.        areas other than a LIS; specifically, as single ATM networks grow to
  3501.        replace many Ethernet local LAN segments and as these networks 
  3502.     become
  3503.        globally connected, the application of IP and ARP will be treated
  3504.        differently.  This memo considers only the application of ATM as a
  3505.        direct replacement for the                                          
  3506.  
  3507.   "Definitions of Managed Objects for Classical IP and ARP Over ATM Using 
  3508.   SMIv2", M. Greene, T Kuo, J. Luciani, K. White, 07/14/1997, 
  3509.   <draft-ietf-ion-mib-04.txt>                                              
  3510.  
  3511.     The purpose of this memo is to define the Management Information Base 
  3512.     (MIB) for supporting Classical IP and ARP over ATM as specified in 
  3513.     Classical IP and ARP over ATM, refer to reference [3]. Support of an 
  3514.     ATM interface by an IP layer will require implementation of objects 
  3515.     from several Management Information Bases (MIBs) as well as their 
  3516.     enhancement in order to enable usage of ATM transports. It is the 
  3517.     intent of this MIB to fully adhere to all prerequisite MIBs unless 
  3518.     explicitly stated. Deviations will be documented in corresponding 
  3519.     conformance statements. The specification of this MIB will utilize the 
  3520.     Structure of Management Information (SMI) for Version 2 of the Simple 
  3521.     Network Management Protocol Version (refer to RFC1902, reference [1]). 
  3522.  
  3523.   "Server Cache Synchronization Protocol (SCSP)", Joel Halpern, G. 
  3524.   Armitage, J. Luciani, 10/30/1997, <draft-ietf-ion-scsp-02.txt>           
  3525.  
  3526.        This document describes the Server Cache Synchronization Protocol
  3527.        (SCSP) and is written in terms of SCSP's use within Non Broadcast
  3528.        Multiple Access (NBMA) networks; although, a somewhat straight
  3529.        forward usage is applicable to BMA networks.  SCSP attempts to solve
  3530.        the generalized cache synchronization/cache-replication problem for
  3531.        distributed protocol entities.  However, in this document, SCSP is
  3532.        couched in terms of the client/server paradigm in which distributed
  3533.        server entities, which are bound to a Server Group (SG) through some
  3534.     means, wish to synchronize the contents (or a portion thereof) of
  3535.        their caches which contain information about the state of clients
  3536.        being served.                                                       
  3537.  
  3538.   "ATM Signalling Support for IP over ATM - UNI Signalling 4.0 Update", M. 
  3539.   Perez, 10/16/1997, <draft-ietf-ion-sig-uni4.0-05.txt>                    
  3540.  
  3541.        This memo describes how to efficiently use the ATM call control
  3542.        signalling procedures defined in UNI Signalling 4.0 [SIG40] to
  3543.        support IP over ATM environments as described in RFC XXX [LAUB97] 
  3544.     and
  3545.        in [LUC97]. Among the new features found in UNI Signalling 4.0 are
  3546.        Available Bit Rate signalling and traffic parameter negotiation.
  3547.        This draft highlights the features of UNI Signalling 4.0 that 
  3548.     provide
  3549.        IP entities capabilities for requesting ATM service in sites with 
  3550.     SVC
  3551.        support, whether it is private ATM or publicly provisioned ATM, in
  3552.        which case the SVC support is probably configured inside PVPs.
  3553.      
  3554.        This document is only relevant to IP when used as the well known
  3555.        ''best effort'' connectionless service. In particular, this means 
  3556.     that
  3557.        this document does not pertain to IP in the presence of implemented
  3558.        IP Integrated Services.  The topic of IP with Integrated Services
  3559.        over ATM will be handled by a different specification or set of
  3560.        specifications being worked on in the ISSLL WG.
  3561.      
  3562.        This specification is follow-on to RFC 1755, ''ATM Signaling Support
  3563.     for IP over ATM'', which is based on UNI 3.1 signalling [UNI95].
  3564.        Readers are assumed to be familiar with RFC 1755.                   
  3565.  
  3566.   "IPv6 over Non-Broadcast Multiple Access (NBMA) networks", G. Armitage, 
  3567.   M. Jork, P. Schulter, G. Harter, 10/13/1997, <draft-ietf-ion-ipv6-00.txt>
  3568.  
  3569.     This document describes a general architecture for IPv6 over NBMA
  3570.        networks. It forms the basis for subsidiary companion documents that
  3571.        describe details for various specific NBMA technologies (such as ATM
  3572.        or Frame Relay). The IPv6 over NBMA architecture allows conventional
  3573.        host-side operation of the IPv6 Neighbor Discovery protocol, while
  3574.        also supporting the establishment of 'shortcut' NBMA forwarding 
  3575.     paths
  3576.        when dynamically signaled NBMA links are available. Operations over
  3577.        administratively configured Point to Point NBMA links are also
  3578.        described.
  3579.      
  3580.        Dynamic NBMA shortcuts are achieved through the use of IPv6 Neighbor
  3581.        Discovery protocol operation within Logical Links, and inter-router
  3582.        NHRP for the discovery of off-Link NBMA destinations. Both  
  3583.     flow-triggered and explicitly source-triggered shortcuts are supported.
  3584.  
  3585.   "Definitions of Managed Objects for the NBMA Next Hop Resolution Protocol
  3586.   (NHRP)", M. Greene, J. Luciani, 01/31/1997, 
  3587.   <draft-ietf-ion-nhrp-mib-01.txt>                                         
  3588.  
  3589.     This memo defines an experimental portion of the Management Information
  3590.     Base (MIB) for use with network management protocols in the Internet 
  3591.     community.  In particular, it describes managed objects for the Next 
  3592.     Hop Resolution Protocol (NHRP) as defined in [1].                      
  3593.     This memo specifies a MIB module in a manner that is both compliant to 
  3594.     the SNMPv2 SMI, and semantically identical to the peer SNMPv1 
  3595.     definitions.     This memo does not specify a standard for the Internet
  3596.     community.                                                             
  3597.  
  3598.   "Multiprotocol Interconnect over Frame Relay", C. Brown, A. Malis, T. 
  3599.   Bradley, 05/07/1997, <draft-ietf-ion-fr-update-03.txt>                   
  3600.  
  3601.     This memo describes an encapsulation method for carrying network 
  3602.     interconnect traffic over a Frame Relay backbone.  It covers aspects of
  3603.     both Bridging and Routing.                                             
  3604.     Systems with the ability to transfer both the encapsulation method 
  3605.     described in this document, and others must have a priori knowledge of 
  3606.     which virtual circuits will carry which encapsulation method and this 
  3607.     encapsulation must only be used over virtual circuits that have been 
  3608.     explicitly configured for its use.                                     
  3609.  
  3610.   "Classical IP to NHRP Transition", J. Luciani, 05/15/1997, 
  3611.   <draft-ietf-ion-transition-02.txt>                                       
  3612.  
  3613.     This document describes methods and procedures for the graceful 
  3614.     transition from an ATMARP LIS[1] to an NHRP LIS[2] network model over 
  3615.     ATM.                                                                   
  3616.  
  3617.   "Inverse Address Resolution Protocol", C. Brown, A. Malis, T. Bradley, 
  3618.   05/07/1997, <draft-ietf-ion-inarp-update-01.txt>                         
  3619.  
  3620.     This memo describes additions to ARP that will allow a station to 
  3621.     request a protocol address corresponding to a given hardware address.  
  3622.     Specifically, this applies to Frame Relay stations that may have a Data
  3623.     Link Connection Identifier (DLCI), the Frame Relay equivalent of a 
  3624.     hardware address, associated with an established Permanent Virtual 
  3625.     Circuit (PVC), but do not know the protocol address of the station on 
  3626.     the other side of this connection.  It will also apply to other 
  3627.     networks with similar circumstances.                                   
  3628.  
  3629.   "Definitions of Managed Objects for Multicast over UNI 3.0/3.1 based ATM 
  3630.   Networks", M. Greene, C. Chung, 09/15/1997, 
  3631.   <draft-ietf-ion-mars-mib-03.txt>                                         
  3632.  
  3633.        This memo defines an experimental portion of the Management
  3634.        Information Base (MIB) for use with network management protocols in
  3635.        the Internet community.  In particular, it describes managed objects
  3636.        for IP hosts and routers that use a Multicast Address Resolution
  3637.        Server (MARS) to support IP multicast over ATM, as described in
  3638.        'Support for Multicast over UNI 3.0/3.1 based ATM Networks' [1].
  3639.     
  3640.        This memo specifies a MIB module in a manner that is both compliant
  3641.        to the SNMPv2 SMI, and semantically identical to the peer SNMPv1
  3642.        definitions.
  3643.     
  3644.        This memo does not specify a standard for the Internet community.   
  3645.  
  3646.   "NHRP for Destinations off the NBMA Subnetwork", Y Rekhter, 02/03/1997, 
  3647.   <draft-ietf-ion-r2r-nhrp-00.txt>                                         
  3648.  
  3649.     The NBMA Next Hop Resolution Protocol (NHRP) [NHRP] specifies a 
  3650.     mechanism that allows a source station (e.g., a host or a router) on an
  3651.     NBMA subnetwork to find the NBMA subnetwork address address of a 
  3652.     destination station when the destination station is connected to the 
  3653.     NBMA subnetwork. For the case where the destination station is off the 
  3654.     NBMA subnetwork the mechanism described in [NHRP] allows to determine 
  3655.     the NBMA subnetwork address of an egress router from the NBMA 
  3656.     subnetwork that is ``nearest'' to the destination station.  However, 
  3657.     the ability of determining the egress router is constrained to the 
  3658.     destinations that are directly connected to the egress router.         
  3659.     This document describes extensions to the NBMA Next Hop Resolution 
  3660.     Protocol (NHRP) [NHRP] that allow to acquire and maintain the 
  3661.     information about the egress router without constraining the 
  3662.     destination(s) to be directly connected to the egress router.          
  3663.  
  3664.   "Intra-LIS IP multicast among routers over ATM using Sparse Mode PIM", D.
  3665.   Farinacci, David Meyer, Y Rekhter, 08/22/1997, 
  3666.   <draft-ietf-ion-intralis-multicast-01.txt>                               
  3667.  
  3668.     This document describes how intra-LIS IP multicast can be efficiently 
  3669.     supported among routers over ATM without using the Multicast Address 
  3670.     Resolution Server (MARS). The method described here is specific to 
  3671.     Sparse Mode PIM [PIM-SM], and relies on the explicit join mechanism 
  3672.     inherent in PIM-SM to notify routers when they should create group 
  3673.     specific point-to-multipoint VCs.                                      
  3674.  
  3675.   "A Distributed ATMARP Service Using SCSP", J. Luciani, B. Fox, 
  3676.   04/16/1997, <draft-ietf-ion-scsp-atmarp-00.txt>                          
  3677.  
  3678.     This document describes a method for distributing an ATMARP service 
  3679.     within a LIS[1].  This method uses the Server Cache Synchronization 
  3680.     Protocol (SCSP)[2] to synchronize the ATMARP server databases within a 
  3681.     LIS.  When SCSP is used to synchronize the caches of ATMARP servers in 
  3682.     a LIS, the LIS defines the boundary of an SCSP Server Group (SG).      
  3683.  
  3684.   "A Distributed NHRP Service Using SCSP", J. Luciani, 10/29/1997, 
  3685.   <draft-ietf-ion-scsp-nhrp-02.txt>                                        
  3686.  
  3687.        This document describes a method for distributing an NHRP service
  3688.        within a LIS[1].  This method uses the Server Cache Synchronization
  3689.        Protocol (SCSP)[2] to synchronize the client information databases
  3690.        held by NHRP Servers (NHSs) within a LIS.                           
  3691.  
  3692.   "ILMI-Based Server Discovery for ATMARP", Michael Davison, 08/20/1997, 
  3693.   <draft-ietf-ion-discov-atmarp-00.txt>                                    
  3694.  
  3695.        This memo defines how ILMI-based Server Discovery, which provides a
  3696.        method for ATM-attached hosts and routers to dynamically determine
  3697.        the ATM address of servers,  shall be used to locate ATMARP servers.
  3698.  
  3699.   "ILMI-Based Server Discovery for MARS", Michael Davison, 08/20/1997, 
  3700.   <draft-ietf-ion-discov-mars-00.txt>                                      
  3701.  
  3702.        This memo defines how ILMI-based Server Discovery, which provides a
  3703.        method for ATM-attached hosts and routers to dynamically determine
  3704.        the ATM address of servers,  shall be used to locate MARS servers.  
  3705.  
  3706.   "A Distributed MARS Service Using SCSP", J. Luciani, A. Gallo, 
  3707.   07/25/1997, <draft-ietf-ion-scsp-mars-00.txt>                            
  3708.  
  3709.     This document describes a method for distributing a MARS service within
  3710.     a LIS[1].  This method uses the Server Cache Synchronization Protocol 
  3711.     (SCSP)[2] to synchronize the MARS Server databases within a LIS.  When 
  3712.     SCSP is used to synchronize the caches of MARS Servers in a LIS, the 
  3713.     LIS defines the boundary of an SCSP Server Group (SG).                 
  3714.  
  3715.   "Intra-area IP unicast among routers over legacy ATM", Juha Heinanen, 
  3716.   07/25/1997, <draft-ietf-ion-intra-area-unicast-00.txt>                   
  3717.  
  3718.     This document describes how IP unicast can be efficiently implemented 
  3719.     among routers belonging to the same area of a routing domain, where the
  3720.     connectivity is provided by a legacy ATM network as defined by the ATM 
  3721.     Forum or ITU.  This proposal is designed to be complementary to IP 
  3722.     multicast solutions such as the one described in [1].                  
  3723.  
  3724.   "ILMI-Based Server Discovery for NHRP", Michael Davison, 08/20/1997, 
  3725.   <draft-ietf-ion-discov-nhrp-00.txt>                                      
  3726.  
  3727.        This memo defines how ILMI-based Server Discovery, which provides a
  3728.        method for ATM-attached hosts and routers to dynamically determine
  3729.        the ATM address of servers,  shall be used to locate NHRP servers.  
  3730.  
  3731.   "IPv6 over ATM Networks", G. Armitage, M. Jork, P. Schulter, G. Harter, 
  3732.   10/13/1997, <draft-ietf-ion-ipv6-atm-00.txt>                             
  3733.  
  3734.        This document is a companion to the ION working group's architecture
  3735.        document 'IPv6 over Non Broadcast Multiple Access (NBMA) networks'.
  3736.        It provides specific details on how to apply the IPv6 over NBMA
  3737.        architecture to ATM networks. This architecture allows conventional
  3738.        host-side operation of the IPv6 Neighbor Discovery protocol, while
  3739.        also supporting the establishment of 'shortcut' ATM forwarding paths
  3740.        (when using SVCs).  Operation over administratively configured Point
  3741.        to Point PVCs is also supported.                                    
  3742.  
  3743. IP Over IEEE 1394 (ip1394)
  3744. --------------------------
  3745.  
  3746.   "Ipv4 over IEEE 1394", Peter Johansson, 10/27/1997, 
  3747.   <draft-ietf-ip1394-ipv4-04.txt,.ps>                                      
  3748.  
  3749.     This document specifies how to use IEEE Std 1394-1995, Standard for a
  3750.           High Performance Serial Bus (and its supplements), for the 
  3751.     transport of
  3752.           Internet Protocol Version 4 (IPv4) datagrams. It defines the 
  3753.     necessary
  3754.           methods, data structures and code for that purpose and 
  3755.     additionally
  3756.           defines a standard method for Address Resolution Protocol (ARP). 
  3757.  
  3758. IP over Cable Data Network (ipcdn)
  3759. ----------------------------------
  3760.  
  3761.   "Cable Device Management Information Base for MCNS compliant Cable Modems
  3762.   and Cable Modem Termination Systems", G. Roeck, 09/09/1997, 
  3763.   <draft-ietf-ipcdn-cable-device-mib-01.txt>                               
  3764.  
  3765.     This memo defines an experimental portion of the Management Information
  3766.     Base (MIB) for use with network management protocols in the Internet
  3767.     community.  In particular, it defines a basic set of managed objects 
  3768.     for
  3769.     SNMP-based management of MCNS compliant Cable Modems and Cable Modem
  3770.     Termination Systems.
  3771.      
  3772.     This memo specifies a MIB module in a manner that is compliant to the
  3773.     SNMPv2 SMI.  The set of objects is consistent with the SNMP framework
  3774.     and existing SNMP standards.
  3775.      
  3776.     This memo does not specify a standard for the Internet community.
  3777.      
  3778.     This memo is a product of the IPCDN working group within the Internet
  3779.     Engineering Task Force.  Comments are solicited and should be addressed
  3780.     to the working group's mailing list at ipcdn@terayon.com and/or the
  3781.     author.                                                                
  3782.  
  3783.   "Radio Frequency (RF) Interface Management Information Base for MCNS 
  3784.   compliant RF interfaces", G. Roeck, 09/03/1997, 
  3785.   <draft-ietf-ipcdn-rf-interface-mib-01.txt>                               
  3786.  
  3787.     This memo defines an experimental portion of the Management Information
  3788.     Base (MIB) for use with network management protocols in the Internet
  3789.     community.  In particular, it defines a basic set of managed objects 
  3790.     for
  3791.     SNMP-based management of MCNS compliant Radio Frequency (RF) 
  3792.     interfaces.
  3793.      
  3794.     This memo specifies a MIB module in a manner that is compliant to the
  3795.     SNMPv2 SMI.  The set of objects is consistent with the SNMP framework
  3796.     and existing SNMP standards.
  3797.      
  3798.     This memo does not specify a standard for the Internet community.
  3799.      
  3800.     This memo is a product of the IPCDN working group within the Internet
  3801.     Engineering Task Force.  Comments are solicited and should be addressed
  3802.     to the working group's mailing list at ipcdn@terayon.com and/or the
  3803.     author.                                                                
  3804.  
  3805.   "IP Over Cable Data Networks - Terms of Reference", Mike St. Johns, 
  3806.   07/29/1997, <draft-ietf-ipcdn-tor-00.txt>                                
  3807.  
  3808.     This document describes a number of possible architectures and design
  3809.     considerations for an IP-over-Cable data system.  It sets the basic
  3810.     framework for discussion and creation of the document set described in
  3811.     the charter for the working group.
  3812.                                                                            
  3813.  
  3814.   "Logical IP Subnetworks over IEEE 802.14 Services", Mark Laubach, 
  3815.   08/01/1997, <draft-ietf-ipcdn-ipover-802d14-00.txt>                      
  3816.  
  3817.     This memo defines an initial application of classical IP and ARP in
  3818.        an IEEE 802.14 Community Access Television (CATV) Residential Access
  3819.        Network environment.  IEEE 802.14 services provide two independent
  3820.        link layer service interfaces which are available to support IP
  3821.        residential access networking services: traditional Ethernet 
  3822.     bridging
  3823.        (via IEEE 802.1D layer services) and residential ATM networking
  3824.        services.
  3825.      
  3826.        In this memo, the term Logical IP Subnetwork (LIS) is defined to
  3827.        apply to Classical IP over ATM LIS's operating over IEEE 802.14
  3828.        services as well as traditional IP over Ethernet operating over IEEE
  3829.        802.14 services.
  3830.      
  3831.        The recommendations in this draft rely on existing IETF standards 
  3832.     for
  3833.        the family of Classical IP and ARP over ATM (IPOA) services and for
  3834.        IP and ARP over Broadcast Ethernet networks.  The tree-based
  3835.        hierarchic nature of the IEEE 802.14 MAC subnetwork permits
  3836.        convenient extensions to Classical IPOA model for broadcast and
  3837.        multicast in the downstream direction of the CATV plant.            
  3838.  
  3839.   "Logical IP Subnetworks over MCNS Data Link Services", Gerry White, 
  3840.   08/28/1997, <draft-ietf-ipcdn-ip-over-mcns-00.txt>                       
  3841.  
  3842.        This memo defines an initial application of IP and ARP in an MCNS
  3843.        Community Access Television (CATV) Residential Access Network
  3844.        environment where the cable system is used for bi-directional data
  3845.        transfer. The MCNS network provides a traditional Ethernet or 802.2
  3846.        link layer service between a cable system head end and the customer
  3847.        premises using the cable television system infrastructure.  This
  3848.        interface is available via IEEE 802.1D layer services to support IP
  3849.        residential access networking services.
  3850.      
  3851.        In this memo, the term Logical IP Subnetwork (LIS) is defined to
  3852.        apply to traditional IP over Ethernet operating over MCNS services.
  3853.      
  3854.        The recommendations in this draft rely on existing IETF standards 
  3855.     for
  3856.        IP and ARP over Broadcast Ethernet networks.                        
  3857.  
  3858. IPNG (ipngwg)
  3859. -------------
  3860.  
  3861.   "Generic Packet Tunneling in IPv6 Specification", A. Conta, Steve 
  3862.   Deering, 06/24/1997, <draft-ietf-ipngwg-ipv6-tunnel-07.txt>              
  3863.  
  3864.     This document defines the model and generic mechanisms for IPv6 
  3865.     encapsulation of Internet packets, such as IPv6 and IPv4.  The model 
  3866.     and mechanisms can be applied to other protocol packets as well, such 
  3867.     as AppleTalk, IPX, CLNP, or others.                                    
  3868.  
  3869.   "Link Local Addressing and Name Resolution in IPv6", D. Harrington, 
  3870.   01/29/1997, <draft-ietf-ipngwg-linkname-01.txt>                          
  3871.  
  3872.     This draft proposes an experimental mechanism by which IPv6 link-local 
  3873.     addresses and associated system names may be distributed among 
  3874.     interconnected hosts, for use by users and applications.  It provides 
  3875.     an overview of the problem, a proposed solution (including suggested 
  3876.     protocol details), and lists various related issues. This work is 
  3877.     introduced to the IPng Working Group initially, although it might also 
  3878.     have implications or concerns relevant to individuals working on 
  3879.     directory services and other areas.                                    
  3880.  
  3881.   "IPv6 Router Alert Option", C. Partridge, D Katz, Ran Atkinson, A. 
  3882.   Jackson, 07/30/1997, <draft-ietf-ipngwg-ipv6router-alert-03.txt>         
  3883.  
  3884.     This memo describes a new IPv6 Hop-by-Hop Option type that alerts
  3885.        transit routers to more closely examine the contents of an IP
  3886.        datagram.  This option is useful for situations where a datagram
  3887.        addressed to a particular destination contains information that may
  3888.        require special processing by routers along the path.               
  3889.  
  3890.   "IPv6 Multicast Address Assignments", Bob Hinden, Steve Deering, 
  3891.   07/16/1997, <draft-ietf-ipngwg-multicast-assgn-04.txt>                   
  3892.  
  3893.     This document defines the initial assignment of IPv6 multicast 
  3894.     addresses.  It is based on the 'IP Version 6 Addressing Architecture' 
  3895.     [ADDARCH] and current IPv4 multicast address assignment found in 
  3896.     ftp://venera.isi.edu/in-notes/iana/assignments/multicast-addresses. It 
  3897.     adapts the IPv4 assignments that are relevant to IPv6 assignments. IPv4
  3898.     assignments that were not relevant were not converted into IPv6 
  3899.     assignments.  Comments are solicited on this conversion.               
  3900.     All other IPv6 multicast addresses are reserved.                       
  3901.     Sections 2 and 3 specify reserved and preassigned IPv6 multicast 
  3902.     addresses.           [ADDRARCH] defines rules for assigning new IPv6 
  3903.     multicast addresses.                                                   
  3904.     The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 
  3905.     'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this 
  3906.     document are to be interpreted as described in [RFC 2119].             
  3907.  
  3908.   "IP Version 6 over PPP", Dimitry Haskin, E. Allen, 07/02/1997, 
  3909.   <draft-ietf-ipngwg-ipv6-over-ppp-02.txt>                                 
  3910.  
  3911.     The Point-to-Point Protocol (PPP) [1] provides a standard method of 
  3912.     encapsulating Network Layer protocol information over point-to-point 
  3913.     links.  PPP also defines an extensible Link Control Protocol, and 
  3914.     proposes a family of Network Control Protocols (NCPs) for establishing 
  3915.     and configuring different network-layer protocols.                     
  3916.     This document defines the method for transmission of IP Version 6 [2] 
  3917.     packets over PPP links as well as the Network Control Protocol (NCP) 
  3918.     for establishing and configuring the IPv6 over PPP. It also specifies 
  3919.     the method of forming IPv6 link-local addresses on PPP links.          
  3920.  
  3921.   "Management Information Base for IP Version 6:  UDP and TCP Groups", 
  3922.   Dimitry Haskin, S. Onishi, 03/24/1997, 
  3923.   <draft-ietf-ipngwg-ipv6-udp-tcp-mib-01.txt>                              
  3924.  
  3925.     This document is one in the series of documents that define various MIB
  3926.     object groups for IPv6.  Specifically, the UDP and TCP groups are 
  3927.     defined in this document.                                              
  3928.     This memo defines an experimental portion of the Management Information
  3929.     Base (MIB) for use with network management protocols in the IPv6-based 
  3930.     internets.                                                      This 
  3931.     document specifies a MIB module in a manner that is both compliant to 
  3932.     the SNMPv2 SMI, and semantically identical to the peer SNMPv1 
  3933.     definitions.                                                           
  3934.  
  3935.   "Management Information Base for IP Version 6:  Textual Conventions and 
  3936.   General Group", Dimitry Haskin, S. Onishi, 06/10/1997, 
  3937.   <draft-ietf-ipngwg-ipv6-mib-02.txt>                                      
  3938.  
  3939.     This document is one in the series of documents that provide MIB 
  3940.     definitions for IP Version 6.  Specifically, the IPv6 MIB textual 
  3941.     conventions as well as the IPv6 MIB General group is defined in this 
  3942.     document.                                                              
  3943.     This memo defines an experimental portion of the Management Information
  3944.     Base (MIB) for use with network management protocols in the IPv6-based 
  3945.     internets.                                                      This 
  3946.     document specifies a MIB module in a manner that is both compliant to 
  3947.     the SNMPv2 SMI, and semantically identical to the peer SNMPv1 
  3948.     definitions.                                                           
  3949.  
  3950.   "Management Information Base for IP Version 6:  ICMPv6 Group", Dimitry 
  3951.   Haskin, S. Onishi, 03/24/1997, <draft-ietf-ipngwg-ipv6-icmp-mib-01.txt>  
  3952.  
  3953.     This document is one in the series of documents that define various MIB
  3954.     object groups for IPv6.  Specifically, the ICMPv6 group is defined in 
  3955.     this document.                                                         
  3956.     This memo defines an experimental portion of the Management Information
  3957.     Base (MIB) for use with network management protocols in the IPv6-based 
  3958.     internets.                                                      This 
  3959.     document specifies a MIB module in a manner that is both compliant to 
  3960.     the SNMPv2 SMI, and semantically identical to the peer SNMPv1 
  3961.     definitions.                                                           
  3962.  
  3963.   "GSE - An Alternate Addressing Architecture for IPv6", Michael O'Dell, 
  3964.   02/24/1997, <draft-ietf-ipngwg-gseaddr-00.txt>                           
  3965.  
  3966.     This document presents an alternative addressing architecture for IPv6 
  3967.     which controls global routing growth by very aggressive topological 
  3968.     aggregation. It includes support for scalable multi-homing as a 
  3969.     distinguished service.  It provides for future independent evolution of
  3970.     routing and forwarding models with essentially no impact on end 
  3971.     systems.  Finally, it frees sites and service resellers from the 
  3972.     tyranny of CIDR-based aggregation by providing transparent re-homing of
  3973.     both.                                                                  
  3974.  
  3975.   "Transmission of IPv6 Packets over Ethernet Networks", M. Crawford, 
  3976.   09/26/1997, <draft-ietf-ipngwg-trans-ethernet-03.txt>                    
  3977.  
  3978.         This document specifies the frame format for transmission of IPv6
  3979.         packets and the method of forming IPv6 link-local addresses and
  3980.         statelessly autoconfigured addresses on Ethernet networks.  It also
  3981.         specifies the content of the Source/Target Link-layer Address 
  3982.     option
  3983.         used in Router Solicitation, Router Advertisement, Neighbor
  3984.         Solicitation, Neighbor Advertisement and Redirect messages when
  3985.         those messages are transmitted on an Ethernet.
  3986.      
  3987.         This document replaces RFC 1972, 'A Method for the Transmission of
  3988.         IPv6 Packets over Ethernet Networks', which will become historic.  
  3989.  
  3990.   "Transmission of IPv6 Packets over FDDI Networks", M. Crawford, 
  3991.   09/26/1997, <draft-ietf-ipngwg-trans-fddi-net-03.txt>                    
  3992.  
  3993.         This document specifies the frame format for transmission of IPv6
  3994.         packets and the method of forming IPv6 link-local addresses and
  3995.         statelessly autoconfigured addresses on FDDI networks.  It also
  3996.         specifies the content of the Source/Target Link-layer Address 
  3997.     option
  3998.         used in Router Solicitation, Router Advertisement, Neighbor
  3999.         Solicitation, Neighbor Advertisement and Redirect messages when
  4000.         those messages are transmitted on an FDDI network.
  4001.      
  4002.         This document replaces RFC 2019, 'Transmission of IPv6 Packets Over
  4003.         FDDI', which will become historic.                                 
  4004.  
  4005.   "Synthesis of Routing Goop and AAAA Records in IPv6", J. Bound, 
  4006.   03/25/1997, <draft-ietf-ipngwg-dns-rr-rgadd-00.txt>                      
  4007.  
  4008.     This document is a proposal to redefine the existing DNS AAAA resource 
  4009.     record into two resource records: an RG record to define the routing 
  4010.     topology of an IPv6 address and an aAA record to define the End System 
  4011.     Identifier of an IPv6 address.  The document will define the synthesis 
  4012.     of the RG and aAA record at the DNS primary server, which will return 
  4013.     an AAAA record to DNS resolvers.  The objective of this work is to 
  4014.     split the AAAA record in the DNS into location and identifier to 
  4015.     provide future capabilities for dynamic renumbering of addresses.  This
  4016.     work was spawned by the GSE - Alternate Addressing Architecture 
  4017.     Proposal for IPv6.                                                     
  4018.  
  4019.   "IP Version 6 Addressing Architecture", Bob Hinden, Steve Deering, 
  4020.   03/26/1997, <draft-ietf-ipngwg-ipv6-arch-00.txt>                         
  4021.  
  4022.     This specification defines the addressing architecture of the IP 
  4023.     Version 6 protocol [IPV6].  The document includes the IPv6 addressing 
  4024.     model, text representations of IPv6 addresses, definition of IPv6 
  4025.     unicast addresses, anycast addresses, and multicast addresses, and an 
  4026.     IPv6 nodes required addresses.                                         
  4027.  
  4028.   "Router Renumbering for IPv6", Bob Hinden, M. Crawford, 07/30/1997, 
  4029.   <draft-ietf-ipngwg-router-renum-01.txt>                                  
  4030.  
  4031.         IPv6 Neighbor Discovery [ND] and Address Autoconfiguration [AA]
  4032.         conveniently make initial assignments of address prefixes to hosts.
  4033.         Aside from the problem of connection survival across a renumbering
  4034.         event, these two mechanisms also simplify the reconfiguration of
  4035.         hosts when the set of valid prefixes changes.
  4036.      
  4037.         This document defines a mechanism called Router Renumbering (RR)
  4038.         which allows address prefixes on routers to be configured and
  4039.         reconfigured almost as easily as the combination of Neighbor
  4040.         Discovery and Address Autoconfiguration works for hosts.  It
  4041.         provides a means for a network manager to make updates to the
  4042.         prefixes used by and advertised by IPv6 routers throughout a site.
  4043.      
  4044.                                                                            
  4045.  
  4046.   "Separating Identifiers and Locators in Addresses:  An Analysis of the 
  4047.   GSE Proposal for IPv6", Lixia Zhang, Allison Mankin, J. Stewart, Thomas 
  4048.   Narten, M. Crawford, 09/16/1997, <draft-ietf-ipngwg-esd-analysis-01.txt> 
  4049.  
  4050.     On February 27-28, 1997, the IPng Working Group held an interim
  4051.        meeting in Palo Alto, California to consider adopting Mike O'Dell's
  4052.        'GSE - An Alternate Addressing Architecture for IPv6' proposal 
  4053.     [GSE].
  4054.        In GSE, 16-byte IPv6 addresses are split into three portions: a
  4055.        globally unique End System Designator (ESD), a Site Topology    
  4056.     Partition (STP) and a Routing Goop (RG) portion. The STP corresponds
  4057.        (roughly) to a site's subnet portion of an IPv4 address, whereas the
  4058.        RG identifies the attachment point to the public Internet. Routers
  4059.        use the RG+STP portions of addresses (called 'Routing Stuff' in this
  4060.        document) to route packets to the link to which the destination is
  4061.        directly attached; the ESD is used to deliver the packet across the
  4062.        last hop link. An important idea in GSE is that nodes within a site
  4063.        do not know the RG portion of their addresses. A border router at 
  4064.     the
  4065.        site's Internet connect point would dynamically replace the RG part
  4066.        of source addresses of all outgoing IP datagrams and the RG part of
  4067.        destination addresses on incoming traffic.
  4068.     
  4069.        This document provides a detailed analysis of the GSE plan. Much of
  4070.        the analysis presented here is an expansion of official meeting
  4071.        minutes, though it also includes issues uncovered by the authors in
  4072.        the process of fully fleshing out the analysis. In summary, the
  4073.        working group eventually decided that the full addresses of nodes
  4074.        within a site should not be hidden from those nodes, so as a result
  4075.        it is not necessary for routers to rewrite the Routing Goop portion
  4076.        of addresses.  However, other parts of the GSE plan were adopted
  4077.        (e.g., having 64-bit interface identifiers with an option for
  4078.        specifying them as globally unique and easing the renumbering of the
  4079.        high-order portion of addresses within DNS).
  4080.     
  4081.        In addition to analyzing the GSE proposal in particular, the 
  4082.     document
  4083.        also studies the general issue of separating network                
  4084.  
  4085.   "IP Version 6 Addressing Architecture", Bob Hinden, Steve Deering, 
  4086.   10/16/1997, <draft-ietf-ipngwg-addr-arch-v2-03.txt>                      
  4087.  
  4088.     This specification defines the addressing architecture of the IP
  4089.        Version 6 protocol [IPV6].  The document includes the IPv6 
  4090.     addressing
  4091.        model, text representations of IPv6 addresses, definition of IPv6
  4092.        unicast addresses, anycast addresses, and multicast addresses, and 
  4093.     an
  4094.        IPv6 node's required addresses.                                     
  4095.  
  4096.   "An IPv6 Aggregatable Global Unicast Address Format", Bob Hinden, Michael
  4097.   O'Dell, Steve Deering, 07/16/1997, 
  4098.   <draft-ietf-ipngwg-unicast-aggr-02.txt>                                  
  4099.  
  4100.     This document defines an IPv6 aggregatable global unicast address 
  4101.     format for use in the Internet.  The address format defined in this 
  4102.     document is consistent with the IPv6 Protocol [IPV6] and the 'IPv6 
  4103.     Addressing Architecture' [ARCH].  It is designed to facilitate scalable
  4104.     Internet routing.                                                      
  4105.     This documented replaces RFC 2073, 'An IPv6 Provider-Based Unicast 
  4106.     Address Format'.  RFC 2073 will become historic.                       
  4107.     The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 
  4108.     'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this 
  4109.     document are to be interpreted as described in [RFC 2119].             
  4110.  
  4111.   "IPv6 Testing Address Allocation", J. Postel, Bob Fink, Bob Hinden, 
  4112.   07/16/1997, <draft-ietf-ipngwg-testv2-addralloc-01.txt>                  
  4113.  
  4114.     This document describes an allocation plan for IPv6 addresses to be 
  4115.     used in testing IPv6 prototype software.  These addresses are temporary
  4116.     and will be reclaimed in the future.  Any IPv6 system using these 
  4117.     addresses will have to renumber at some time in the future.  These 
  4118.     addresses will not to be routable in the Internet other than for IPv6 
  4119.     testing.            The address format for the IPv6 test address is 
  4120.     consistent with the 'Aggregatable Global Unicast Address Allocation' 
  4121.     [AGGR] and 'TLA and NLA Assignment Rules' [TLAASN].                    
  4122.     This document is intended to replace RFC1897 'IPv6 Testing Address 
  4123.     Allocation', January 1996.  RFC1897 will become historic.              
  4124.     The addresses described in this document are consistent with the IPv6 
  4125.     Addressing Architecture [ARCH].  They may be assigned to nodes 
  4126.     manually, with IPv6 Auto Address Allocation [AUTO], or with DHCP for 
  4127.     IPv6 [DHCPv6].  The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 
  4128.     'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 
  4129.     'OPTIONAL' in this document are to be interpreted as described in [RFC 
  4130.     2119].                                                                 
  4131.  
  4132.   "IP Version 6 Management Information Base for the User Datagram 
  4133.   Protocol", M. Daniele, 06/10/1997, 
  4134.   <draft-ietf-ipngwg-ipv6-udp-mib-00.txt>                                  
  4135.  
  4136.     This document is one in the series of documents that define various MIB
  4137.     objects for IPv6.  Specifically, this document is the MIB module which 
  4138.     defines managed objects for implementations of the User Datagram 
  4139.     Protocol (UDP) over IP Version 6 (IPv6).                               
  4140.     This document also recommends a specific policy with respect to the 
  4141.     applicability of RFC 2013 for implementations of IPv6.   Namely, the 
  4142.     most of managed objects defined in RFC 2013 are independent of which IP
  4143.     versions underly UDP, and only the UDP listener information is IP 
  4144.     version-specific.                                                      
  4145.     This memo defines an experimental portion of the Management Information
  4146.     Base (MIB) for use with network management protocols in the IPv6-based 
  4147.     internets.                                                             
  4148.  
  4149.   "IP Version 6 Management Information Base for the Transmission Control 
  4150.   Protocol", M. Daniele, 06/10/1997, 
  4151.   <draft-ietf-ipngwg-ipv6-tcp-mib-00.txt>                                  
  4152.  
  4153.     This document is one in the series of documents that define various MIB
  4154.     objects for IPv6.  Specifically, this document is the MIB module which 
  4155.     defines managed objects for implementations of the Transmission Control
  4156.     Protocol (TCP) over IP Version 6 (IPv6).                               
  4157.     This document also recommends a specific policy with respect to the 
  4158.     applicability of RFC 2012 for implementations of IPv6.  Namely, the 
  4159.     most of managed objects defined in RFC 2012 are independent of which IP
  4160.     versions underly TCP, and only the TCP connection information is IP 
  4161.     version-specific.                                                      
  4162.     This memo defines an experimental portion of the Management Information
  4163.     Base (MIB) for use with network management protocols in the IPv6-based 
  4164.     internets.                                                             
  4165.  
  4166.   "Transmission of IPv6 Packets over Token Ring Networks", Thomas Narten, 
  4167.   M. Crawford, S. Thomas, 10/27/1997, 
  4168.   <draft-ietf-ipngwg-trans-tokenring-03.txt>                               
  4169.  
  4170.     This memo specifies the MTU and frame format for transmission
  4171.          of IPv6 packets on Token Ring networks. It also specifies the
  4172.          method of forming IPv6 link-local addresses on Token Ring
  4173.          networks and the content of the Source/Target Link-layer
  4174.          Address option used the Router Solicitation, Router
  4175.          Advertisement, Redirect, Neighbor Solicitation and Neighbor
  4176.          Advertisement messages when those messages are transmitted on
  4177.          a Token Ring network.                                             
  4178.  
  4179.   "TLA and NLA Assignment Rules", Bob Hinden, Michael O'Dell, 07/16/1997, 
  4180.   <draft-ietf-ipngwg-tla-assignment-00.txt>                                
  4181.  
  4182.     This document defines assignment rules for Top-Level Aggregation 
  4183.     Identifiers (TLA ID) and Next-Level Aggregation Identifiers (NLA ID) as
  4184.     defined in [AGGR].  These rules apply to registries allocating TLA ID's
  4185.     and to organizations receiving TLA ID's.                               
  4186.     The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 
  4187.     'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this 
  4188.     document are to be interpreted as described in [RFC 2119].             
  4189.  
  4190.   "IPv6 Name Lookups Through ICMP", M. Crawford, 07/25/1997, 
  4191.   <draft-ietf-ipngwg-icmp-namelookups-01.txt>                              
  4192.  
  4193.     IPv4 addresses are translated to fully-qualified domain names (FQDNs) 
  4194.     using the DNS.  Experience shows that the IN-ADDR.ARPA zones used for 
  4195.     this translation tend to be poorly maintained in many cases.  In a 
  4196.     larger internet with more frequent site renumbering, the maintenance of
  4197.     such zones will be even more difficult.                                
  4198.     This document describes a protocol for simply asking an IPv6 node to 
  4199.     supply its FQDN when needed.  The DNS style of authority delegation is 
  4200.     thus eliminated for IPv6 address-to-name translations and the routing 
  4201.     infrastructure plays that role.                                        
  4202.  
  4203.   "Neighbor Discovery for IP Version 6 (IPv6)", W. Simpson, Thomas Narten, 
  4204.   Erik Nordmark, 10/06/1997, <draft-ietf-ipngwg-discovery-v2-00.txt>       
  4205.  
  4206.     This document specifies the Neighbor Discovery protocol for IP         
  4207.     Version 6.  IPv6 nodes on the same link use Neighbor Discovery to
  4208.        discover each other's presence, to determine each other's link-layer
  4209.        addresses, to find routers and to maintain reachability information
  4210.        about the paths to active neighbors.                                
  4211.  
  4212.   "IPv6 Stateless Address Autoconfiguration", Susan Thomson, Thomas Narten,
  4213.   07/30/1997, <draft-ietf-ipngwg-addrconf-v2-00.txt>                       
  4214.  
  4215.     This document specifies the steps a host takes in deciding how to
  4216.        autoconfigure its interfaces in IP version 6. The autoconfiguration
  4217.        process includes creating a link-local address and verifying its
  4218.        uniqueness on a link, determining what information should be
  4219.        autoconfigured (addresses, other information, or both), and in the
  4220.        case of addresses, whether they should be obtained through the
  4221.        stateless mechanism, the stateful mechanism, or both.  This document
  4222.        defines the process for generating a link-local address, the process
  4223.        for generating site-local and global addresses via stateless address
  4224.        autoconfiguration, and the Duplicate Address Detection procedure. 
  4225.     The
  4226.        details of autoconfiguration using the stateful protocol are
  4227.        specified elsewhere.                                                
  4228.  
  4229.   "Internet Protocol, Version 6 (IPv6) Specification", Bob Hinden, Steve 
  4230.   Deering, 07/30/1997, <draft-ietf-ipngwg-ipv6-spec-v2-00.txt>             
  4231.  
  4232.     This document specifies version 6 of the Internet Protocol (IPv6),
  4233.        also sometimes referred to as IP Next Generation or IPng.           
  4234.  
  4235.   "Site prefixes in Neighbor Discovery", Erik Nordmark, 07/30/1997, 
  4236.   <draft-ietf-ipngwg-site-prefixes-00.txt>                                 
  4237.  
  4238.        This document specifies extensions to IPv6 Neighbor Discovery to
  4239.        carry site-prefixes.  The site prefixes are used to reduce the 
  4240.     effect
  4241.        of site renumbering by ensuring that the communication inside a site
  4242.        uses site-local addresses.
  4243.                                                                            
  4244.  
  4245.   "Internet Control Message Protocol (ICMPv6) for the Internet Protocol 
  4246.   Version 6 (IPv6) Specification", A. Conta, Steve Deering, 10/27/1997, 
  4247.   <draft-ietf-ipngwg-icmp-v2-00.txt>                                       
  4248.  
  4249.        This document specifies a set of Internet Control Message Protocol
  4250.        (ICMP) messages for use with version 6 of the Internet Protocol
  4251.        (IPv6).                                                             
  4252.  
  4253. Internet Printing Protocol (ipp)
  4254. --------------------------------
  4255.  
  4256.   "Requirements for an Internet Printing Protocol", F. Wright, 10/16/1997, 
  4257.   <draft-ietf-ipp-req-01.txt>                                              
  4258.  
  4259.     This document is one of a set of documents which together
  4260.               describe all aspects of a new Internet Printing Protocol 
  4261.     (IPP).
  4262.               IPP is an application level protocol that can be used for
  4263.               distributed printing on the Internet. The protocol is heavily
  4264.               influenced by the printing model introduced in the Document
  4265.               Printing Application (ISO/IEC 10175 DPA) standard. Although 
  4266.     DPA
  4267.               identifies the both end user and administrative features, IPP
  4268.     is
  4269.               initially focused only on the end user functionality.
  4270.     
  4271.               The full set of IPP documents include:
  4272.      
  4273.               Requirements for an Internet Printing Protocol
  4274.               Internet Printing Protocol/1.0: Model and Semantics
  4275.               Internet Printing Protocol/1.0: Protocol Specification
  4276.               Rationale for the Structure and Model and Protocol for the
  4277.                   Internet Printing Protocol                               
  4278.  
  4279.   "Internet Printing Protocol/1.0: Model and Semantics", P. Powell, T. 
  4280.   Hasting, R. Herriot, S. Isaacson, R. deBry, 10/27/1997, 
  4281.   <draft-ietf-ipp-model-06.txt>                                            
  4282.  
  4283.              This document is one of a set of documents, which together 
  4284.     describe
  4285.              all aspects of a new Internet Printing Protocol (IPP).  IPP is
  4286.     an
  4287.              application level protocol that can be used for distributed 
  4288.     printing
  4289.              using Internet tools and technology.  The protocol is heavily
  4290.              influenced by the printing model introduced in the Document 
  4291.     Printing
  4292.              Application (DPA) [ISO10175] standard.  Although DPA specifies
  4293.     both
  4294.              end user and administrative features, IPP version 1.0 is 
  4295.     focused only
  4296.              on end user functionality.
  4297.     
  4298.                                                                            
  4299.  
  4300.   "Internet Printing Protocol/1.0: Directory Schema", S. Isaacson, K. 
  4301.   Carter, 06/24/1997, <draft-ietf-ipp-dir-schema-01.txt>                   
  4302.  
  4303.     This document is one of a set of documents which together describe all 
  4304.     aspects of a new Internet Printing Protocol (IPP). IPP is an 
  4305.     application level protocol that can be used for distributed printing 
  4306.     using Internet tools and technology. The protocol is heavily influenced
  4307.     by the printing model introduced in the Document Printing Application 
  4308.     (ISO/IEC 10175 DPA) standard.  Although DPA specifies both end user and
  4309.     administrative features, IPP version 1.0 is focused on end user 
  4310.     functionality.  Although DPA specifies both end user and administrative
  4311.     features, IPP version 1.0 is focused only on end user functionality.   
  4312.  
  4313.   "Internet Printing Protocol/1.0: Security", R. deBry, J. Hadsell, D. 
  4314.   Manchala, X. Riley, J. Wenn, 07/31/1997, <draft-ietf-ipp-security-01.txt>
  4315.  
  4316.     This document is one of a set of documents which together
  4317.               describe all aspects of a new Internet Printing Protocol 
  4318.     (IPP).
  4319.               IPP is an application level protocol that can be used for
  4320.               distributed printing on the Internet. The protocol is heavily
  4321.               influenced by the printing model introduced in the Document
  4322.               Printing Application (ISO/IEC 10175 DPA) standard, which
  4323.               describes a distributed printing service. The full set of IPP
  4324.               documents includes:
  4325.      
  4326.      
  4327.                    Requirements for an Internet Printing Protocol
  4328.                    Internet Printing Protocol/1.0: Model and Semantics
  4329.                    Internet Printing Protocol/1.0: Security
  4330.                    Internet Printing Protocol/1.0: Protocol Specification
  4331.                    Internet Printing Protocol/1.0: Directory Schema
  4332.      
  4333.               This document is the `Internet Printing Protocol/1.0: 
  4334.     Security'
  4335.               document.                                                    
  4336.  
  4337.   "Mapping between LPD and IPP Protocols", J. Martin, T. Hasting, R. 
  4338.   Herriot, N. Jacobs, 07/31/1997, <draft-ietf-ipp-lpd-ipp-map-01.txt>      
  4339.  
  4340.          This Internet-Draft specifies the mapping between (1) the commands
  4341.          and operands of the 'Line Printer Daemon (LPD) Protocol' specified
  4342.          in RFC 1179 and (2) the operations and parameters of the Internet
  4343.          Printing Protocol (IPP).  One of the purposes of this document is
  4344.          to compare the functionality of the two protocols.  Another 
  4345.     purpose
  4346.          is to facilitate implementation of gateways between LPD and IPP.
  4347.      
  4348.          WARNING:  RFC 1179 was not on standards track.  While RFC 1179 was
  4349.          intended to record existing practice, it fell short in some areas.
  4350.          However, this specification maps between (1) the actual current
  4351.          practice of RFC 1179 and (2) IPP.  This document does not attempt
  4352.          to map the numerous divergent extensions to the LPD protocol that
  4353.          have been made by many implementers.
  4354.                                                                            
  4355.  
  4356.   "Internet Printing Protocol/1.0: Protocol Specification", R. Turner, R. 
  4357.   Herriot, Sylvan Butler, Paul Moore, 10/31/1997, 
  4358.   <draft-ietf-ipp-protocol-02.txt>                                         
  4359.  
  4360.      This document is one of a set of documents, which together describe 
  4361.     all
  4362.     aspects of a new Internet Printing Protocol (IPP).  IPP is an
  4363.     application level protocol that can be used for distributed printing
  4364.     using Internet tools and technology.  The protocol is heavily 
  4365.     influenced
  4366.     by the printing model introduced in the Document Printing Application
  4367.     (ISO/IEC 10175 DPA) standard [dpa].  Although DPA specifies both end
  4368.     user and administrative features, IPP version 1.0 is focused only on 
  4369.     end
  4370.     user functionality.
  4371.      
  4372.     The full set of IPP documents includes:
  4373.      
  4374.       Internet Printing Protocol: Requirements
  4375.       Internet Printing Protocol/1.0: Model and Semantics
  4376.       Internet Printing Protocol/1.0: Protocol Specification
  4377.      
  4378.     The requirements document takes a broad look at distributed printing
  4379.     functionality, and it enumerates real-life scenarios that help to
  4380.     clarify the features that need to be included in a printing protocol 
  4381.     for
  4382.     the Internet.  It identifies requirements for three types of users: end
  4383.     users, operators, and administrators.  The requirements document calls
  4384.     out a subset of end user requirements that MUST be satisfied in the 
  4385.     first version of IPP.  Operator and administrator requirements are out
  4386.     of scope for v1.0. The model and semantics document describes a
  4387.     simplified model with abstract objects, their attributes, and their
  4388.     operations. The model introduces a Printer object and a Job object.  
  4389.     The
  4390.     Job object supports multiple documents per job. The protocol
  4391.     specification is formal document which incorporates the ideas in all 
  4392.     the
  4393.     other documents into a concrete mapping using clearly defined data
  4394.     representations and transport protocol mappings that real implementers
  4395.     can use to develop interoperable client and printer (server) side
  4396.     components.
  4397.      
  4398.     This document is the ''Internet Printing Protocol/1.0: Protocol
  4399.     Specification'' document.                                              
  4400.  
  4401.   "Rationale for the Structure of the Model and Protocol for the Internet 
  4402.   Printing Protocol (IPP)", Steve Zilles, 08/01/1997, 
  4403.   <draft-ietf-ipp-rat-01.txt>                                              
  4404.  
  4405.     This document is one of a set of documents which together describe all 
  4406.     aspects of a new Internet Printing Protocol (IPP). IPP is an 
  4407.     application level protocol that can be used for distributed printing on
  4408.     the Internet. There are multiple parts to IPP, but the primary 
  4409.     architectural components are the Model, the Protocol and an interface 
  4410.     to Directory Services. This document provides a high level overview of 
  4411.     the architecture and provides the rational for the decisions made in 
  4412.     structuring the architecture.                                          
  4413.  
  4414. IP Payload Compression Protocol (ippcp)
  4415. ---------------------------------------
  4416.  
  4417.   "IP Payload Compression Protocol (IPComp)", A. Shacham, 10/01/1997, 
  4418.   <draft-ietf-ippcp-protocol-01.txt>                                       
  4419.  
  4420.     This document describes a protocol intended to provide lossless
  4421.        compression for Internet Protocol datagrams in an Internet
  4422.        environment.                                                        
  4423.  
  4424. IP Security Protocol (ipsec)
  4425. ----------------------------
  4426.  
  4427.   "Internet Security Association and Key Management Protocol (ISAKMP)", D. 
  4428.   Maughan, M. Schertler, M. Schneider, J. Turner, 07/29/1997, 
  4429.   <draft-ietf-ipsec-isakmp-08.txt,.ps>                                     
  4430.  
  4431.     This memo describes a protocol utilizing security concepts necessary 
  4432.     for establishing Security Associations (SA) and cryptographic keys in 
  4433.     an Internet environment.  A Security Association protocol that 
  4434.     negotiates, establishes, modifies and deletes Security Associations and
  4435.     their attributes is required for an evolving Internet, where there will
  4436.     be numerous security mechanisms and several options for each security 
  4437.     mechanism.  The key management protocol must be robust in order to 
  4438.     handle public key generation for the Internet community at large and 
  4439.     private key requirements for those private networks with that 
  4440.     requirement.        The Internet Security Association and Key 
  4441.     Management Protocol (ISAKMP) defines the procedures for authenticating 
  4442.     a communicating peer, creation and management of Security Associations,
  4443.     key generation techniques, and threat mitigation (e.g.  denial of 
  4444.     service and replay attacks).  All of these are necessary to establish 
  4445.     and maintain secure communications (via IP Security Service or any 
  4446.     other security protocol) in an Internet environment.                   
  4447.  
  4448.   "The OAKLEY Key Determination Protocol", H. Orman, 07/25/1997, 
  4449.   <draft-ietf-ipsec-oakley-02.txt>                                         
  4450.  
  4451.     This document describes a protocol, named OAKLEY, by which two 
  4452.     authenticated parties can agree on secure and secret keying material.  
  4453.     The basic mechanism is the Diffie-Hellman key exchange algorithm.      
  4454.     The OAKLEY protocol supports Perfect Forward Secrecy, compatibility 
  4455.     with the ISAKMP protocol for managing security associations, 
  4456.     user-defined abstract group structures for use with the Diffie-Hellman 
  4457.     algorithm, key updates, and incorporation of keys distributed via 
  4458.     out-of-band mechanisms.                                                
  4459.  
  4460.   "The ESP Triple DES Transform", W. Simpson, Naganand Doraswamy, Perry 
  4461.   Metzger, 07/03/1997, <draft-ietf-ipsec-ciph-des3-00.txt>                 
  4462.  
  4463.     This document describes the 'Triple' DES-EDE3-CBC block cipher 
  4464.     transform interface used with the IP Encapsulating Security Payload 
  4465.     (ESP).  It provides compatible migration from RFC-1851.                
  4466.  
  4467.   "IP Authentication Header", Stephen Kent, Ran Atkinson, 10/03/1997, 
  4468.   <draft-ietf-ipsec-auth-header-02.txt>                                    
  4469.  
  4470.        The IP Authentication Header (AH) is used to provide connectionless
  4471.        integrity and data origin authentication for IP datagrams (hereafter
  4472.        referred to as just 'authentication'), and to provide protection
  4473.        against replays.  This latter, optional service may be selected, by
  4474.        the receiver, when a Security Association is established.  AH
  4475.        provides authentication for as much of the IP header as possible, as
  4476.        well as for upper level protocol data.  However, some IP header
  4477.        fields may change in transit and the value of these fields, when the
  4478.        packet arrives at the receiver, may not be predictable by the
  4479.        transmitter.  The values of such fields cannot be protected by AH.
  4480.        Thus the protection provided to the IP header by AH is somewhat
  4481.        piecemeal.  
  4482.     
  4483.        AH may be applied alone, in combination with the IP Encapsulating
  4484.        Security Payload (ESP) [KA97b], or in a nested fashion through the
  4485.        use of tunnel mode (see 'Security Architecture for the Internet
  4486.        Protocol' [KA97a], hereafter referred to as the Security 
  4487.     Architecture
  4488.        document).  Security services can be provided between a pair of
  4489.        communicating hosts, between a pair of communicating security
  4490.        gateways, or between a security gateway and a host.  ESP may be used
  4491.        to provide the same security services, and it also provides a
  4492.        confidentiality (encryption) service.  The primary difference 
  4493.     between
  4494.        the authentication provided by ESP and AH is the extent of the
  4495.        coverage.  Specifically, ESP does not protect any IP header fields
  4496.        unless those fields are encapsulated by ESP (tunnel mode).  For more
  4497.        details on how to use AH and ESP in various network environments, 
  4498.     see    the Security Architecture document [KA97a].
  4499.      
  4500.        It is assumed that the reader is familiar with the terms and 
  4501.     concepts
  4502.        described in the Security Architecture document.  In particular, the
  4503.        reader should be familiar with the definitions of security services
  4504.        offered by AH and ESP,                                              
  4505.  
  4506.   "The resolution of ISAKMP with Oakley", D. Carrel, D. Harkins, 
  4507.   07/16/1997, <draft-ietf-ipsec-isakmp-oakley-04.txt>                      
  4508.  
  4509.     [MSST96] (ISAKMP) provides a framework for authentication and key 
  4510.     exchange but does not define them.  ISAKMP is designed to be key 
  4511.     exchange independant; that is, it is designed to support many different
  4512.     key exchanges.                                                         
  4513.     [Orm96] (Oakley) describes a series of key exchanges-- called 'modes'--
  4514.     and details the services provided by each (e.g. perfect forward secrecy
  4515.     for keys, identity protection, and authentication).                    
  4516.     [Kra96] (SKEME) describes a versatile key exchange technique which 
  4517.     provides anonymity, repudiability, and quick key refreshment.          
  4518.     This document describes a protocol using part of Oakley and part of 
  4519.     SKEME in conjunction with ISAKMP to obtain authenticated keying 
  4520.     material for use with ISAKMP, and for other security associations such 
  4521.     as AH and ESP for the IETF IPsec DOI.                                  
  4522.  
  4523.   "The Internet IP Security Domain of Interpretation for ISAKMP", D. Piper,
  4524.   10/09/1997, <draft-ietf-ipsec-ipsec-doi-05.txt>                          
  4525.  
  4526.        The Internet Security Association and Key Management Protocol
  4527.        (ISAKMP) defines a framework for security association management and
  4528.        cryptographic key establishment for the Internet.  This framework
  4529.        consists of defined exchanges, payloads, and processing guidelines
  4530.        that occur within a given Domain of Interpretation (DOI).  This
  4531.        document defines the Internet IP Security DOI (IPSEC DOI), which
  4532.        instantiates ISAKMP for use with IP when IP uses ISAKMP to negotiate
  4533.        security associations.
  4534.          
  4535.        For a description of how the IPSEC DOI fits into the overall IP
  4536.        Security Documentation framework, please see [ROADMAP].
  4537.          
  4538.        For a list of changes since the previous version of the IPSEC DOI,
  4539.        please see Section 5.                                               
  4540.  
  4541.   "Inline Keying within the ISAKMP Framework.", B. Sommerfeld, 03/26/1997, 
  4542.   <draft-ietf-ipsec-inline-isakmp-01.txt>                                  
  4543.  
  4544.     The current proposal for IP-layer key management [ISAKMP, OAKLEY, 
  4545.     ISAOAK] has fairly high overhead.  Before a security association can be
  4546.     established, at least one pair of messages need to be exchanged between
  4547.     the communicating peers.  For efficiency, this suggests that ISAKMP 
  4548.     setup should be infrequent.  However, general principles of key 
  4549.     management suggest that individual keys should be used as little as 
  4550.     practical and changed as frequently as possible.  Steve Bellovin has 
  4551.     suggested that, ideally, different security associations should be used
  4552.     for each different transport-level connection[BADESP]. This document 
  4553.     discusses a way of structuring a protocol to permit this to happen with
  4554.     minimal overhead, both in round-trip delay at connection setup, and in 
  4555.     bandwidth once the connection is established.          The general 
  4556.     concept of inline or in-band keying here was inspired by SKIP[SKIP].  
  4557.     However, SKIP's approach is burdened by the addition of an extra 
  4558.     intermediate header of perhaps 20 to 28 bytes to every protected 
  4559.     packet, which doubles the bandwidth overhead of protected traffic 
  4560.     compared with ESP with fixed keying.  In order to minimise the 
  4561.     per-packet overhead, an inline keying header                           
  4562.  
  4563.   "Implementation of Virtual Private Network (VPNs) with IP Security", 
  4564.   Naganand Doraswamy, 03/14/1997, <draft-ietf-ipsec-vpn-00.txt>            
  4565.  
  4566.     This document discusses methods for implementing Virtural Private 
  4567.     Networks (VPN) with IP Security (IPSec). We discuss different scenarios
  4568.     in which VPN is implemented and the security implications for each of 
  4569.     these scenarios.                                                       
  4570.  
  4571.   "The ESP RC5-CBC Algorithm", R. Baldwin, R. Pereira, 07/02/1997, 
  4572.   <draft-ietf-ipsec-ciph-rc5-cbc-00.txt>                                   
  4573.  
  4574.     This document describes the RC5 block cipher algorithm as to be used 
  4575.     with the IPSec Encapsulating Security Payload (ESP).                   
  4576.  
  4577.   "The ESP CAST128-CBC Algorithm", G. Carter, R. Pereira, 07/03/1997, 
  4578.   <draft-ietf-ipsec-ciph-cast128-cbc-00.txt>                               
  4579.  
  4580.     This document describes the CAST-128 block cipher algorithm as to be 
  4581.     used with the IPSec Encapsulating Security Payload (ESP).              
  4582.  
  4583.   "A revised encryption mode for ISAKMP/Oakley", H. Krawczyk, P. Cheng, R. 
  4584.   Canetti, 08/05/1997, <draft-ietf-ipsec-revised-enc-mode-01.txt>          
  4585.  
  4586.     The ISAKMP/Oakley document [HC97] describes a proposed standard for
  4587.        using the Oakley Key Exchange Protocol in conjunction with ISAKMP to
  4588.        obtain authenticated and secret keying material for use with ISAKMP,
  4589.        and for other security associations such as AH and ESP for the IETF
  4590.        IPsec DOI.
  4591.      
  4592.        The public-key encryption method of carrying out Phase 1 of the key
  4593.        exchange in the ISAKMP/Oakley document provides significant security
  4594.        advantages over the other alternatives and should be the method of
  4595.        choice in many implementations. Unfortunately, as currently
  4596.        described in [HC97] the method requires two public key
  4597.        encryption and decryption operations from both the Initiator and
  4598.        the Responder. The present document describes a small modification
  4599.        to this method. The resulting scheme requires only one public key
  4600.        encryption and decryption operation from each party, while 
  4601.     maintaining
  4602.        (and even improving on) the strong security properties of the
  4603.        ISAKMP/Oakley public-key encryption mode.
  4604.      
  4605.        Remark: This document is NOT self-contained, it is intended as an
  4606.        addendum to the authentication methods defined in [HC97].
  4607.        In particular, it uses notation and definitions of [HC97].
  4608.        Thus, it is best read in conjunction with [HC97].                   
  4609.  
  4610.   "The ESP DES-CBC Transform", P. Karn, W. Simpson, Perry Metzger, 
  4611.   07/03/1997, <draft-ietf-ipsec-ciph-des-derived-00.txt>                   
  4612.  
  4613.     This document describes the DES-CBC block cipher transform interface 
  4614.     used with the IP Encapsulating Security Payload (ESP).  It provides 
  4615.     compatible migration from RFC-1829.                                    
  4616.  
  4617.   "IP Security Document Roadmap", Rodney Thayer, Naganand Doraswamy, R. 
  4618.   Glenn, 07/30/1997, <draft-ietf-ipsec-doc-roadmap-01.txt>                 
  4619.  
  4620.        The IPsec protocol suite is used to provide privacy and
  4621.        authentication services at the IP layer.  Several documents are used
  4622.        to describe this protocol suite.  The interrelationship and
  4623.        organization of the various documents covering the IPsec protocol 
  4624.     are
  4625.        discussed here.  An explanation of what to find in which document,
  4626.        and what to include in new Encryption Algorithm and Authentication
  4627.        Algorithm documents are described.
  4628.                                                                            
  4629.  
  4630.   "The Use of HMAC-SHA-1-96 within ESP and AH", C. Madson, R. Glenn, 
  4631.   07/02/1997, <draft-ietf-ipsec-auth-hmac-sha196-00.txt>                   
  4632.  
  4633.     This draft describes the use of the HMAC algorithm [RFC-2104] in 
  4634.     conjunction with the SHA-1 algorithm [FIPS-180-1] as an authentication 
  4635.     mechanism within the revised IPSEC Encapsulating Security Payload [ESP]
  4636.     and the revised IPSEC Authentication Header [AH]. HMAC with SHA-1 
  4637.     provides data origin authentication and integrity protection.          
  4638.     Further information on the other components necessary for ESP and AH 
  4639.     implementations is provided by [Thayer97a].                            
  4640.  
  4641.   "The Use of HMAC-MD5-96 within ESP and AH", C. Madson, R. Glenn, 
  4642.   07/02/1997, <draft-ietf-ipsec-auth-hmac-md5-96-00.txt>                   
  4643.  
  4644.     This draft describes the use of the HMAC algorithm [RFC-2104] in 
  4645.     conjunction with the MD5 algorithm [RFC-1321] as an authentication 
  4646.     mechanism within the revised IPSEC Encapsulating Security Payload [ESP]
  4647.     and the revised IPSEC Authentication Header [AH]. HMAC with MD5 
  4648.     provides data origin authentication and integrity protection.          
  4649.     Further information on the other components necessary for ESP and AH 
  4650.     implementations is provided by [Thayer97a].                            
  4651.  
  4652.   "The ESP DES-CBC Cipher Algorithm With Explicit IV", Naganand Doraswamy, 
  4653.   C. Madson, 07/02/1997, <draft-ietf-ipsec-ciph-des-expiv-00.txt>          
  4654.  
  4655.     This document describes the use of the DES Cipher algorithm in Cipher 
  4656.     Block Chaining Mode, with an explicit IV, as a confidentiality 
  4657.     mechanism within the context of the IPSec Encapsulating Security 
  4658.     Payload (ESP).                                                         
  4659.  
  4660.   "ESP with Cipher Block Chaining (CBC)", W. Simpson, 07/03/1997, 
  4661.   <draft-ietf-ipsec-cbc-00.txt>                                            
  4662.  
  4663.     This document describes the Cipher Block Chaining (CBC) mode, used by a
  4664.     number of Internet Encapsulating Security Payload (ESP) transforms.    
  4665.  
  4666.   "The ESP ARCFOUR Algorithm", Rodney Thayer, 07/03/1997, 
  4667.   <draft-ietf-ipsec-ciph-arcfour-00.txt>                                   
  4668.  
  4669.     This draft describes the use of the ARCFOUR [Kaukonen] stream cipher 
  4670.     algorithm to be used with the IPSec Encapsulating Security Payload 
  4671.     [ESP].                                                                 
  4672.  
  4673.   "The ESP DES-XEX3-CBC Transform", W. Simpson, R. Baldwin, 07/03/1997, 
  4674.   <draft-ietf-ipsec-ciph-desx-00.txt>                                      
  4675.  
  4676.     This document describes the 'DESX' DES-XEX3-CBC block cipher transform 
  4677.     interface used with the IP Encapsulating Security Payload (ESP).       
  4678.  
  4679.   "The ESP Blowfish-CBC Algorithm Using an Explicit IV", R. Adams, 
  4680.   07/17/1997, <draft-ietf-ipsec-ciph-blowfish-cbc-00.txt>                  
  4681.  
  4682.     This draft describes the use of the Blowfish [Schneier] block cipher 
  4683.     algorithm to be used with the IPSec Encapsulating Security Payload 
  4684.     (ESP) [Kent97].                                                        
  4685.  
  4686.   "The ESP 3DES-CBC Algorithm Using an Explicit IV", Rodney Thayer, R. 
  4687.   Pereira, 07/21/1997, <draft-ietf-ipsec-ciph-3des-expiv-00.txt>           
  4688.  
  4689.     This document describes the 'Triple' DES-EDE3-CBC block cipher 
  4690.     algorithm used with the IP Encapsulating Security Payload (ESP).  Use 
  4691.     of an explicit IV is described.                                        
  4692.  
  4693.   "IP Encapsulating Security Payload (ESP)", Stephen Kent, Ran Atkinson, 
  4694.   10/06/1997, <draft-ietf-ipsec-esp-v2-01.txt>                             
  4695.  
  4696.        The Encapsulating Security Payload (ESP) header is designed to
  4697.        provide a mix of security services in IPv4 and IPv6.                
  4698.  
  4699.   "The ESP IDEA-CBC Algorithm Using Explicit IV", R. Adams, 07/22/1997, 
  4700.   <draft-ietf-ipsec-ciph-idea-cbc-00.txt>                                  
  4701.  
  4702.     This draft describes the use of the IDEA [Schneier] block cipher 
  4703.     algorithm in CBC mode with the IPSec Encapsulating Security Payload 
  4704.     (ESP) [Kent97].                                                        
  4705.  
  4706.   "The ESP CAST5-128-CBC Transform", W. Simpson, Perry Metzger, 07/30/1997,
  4707.   <draft-ietf-ipsec-ciph-cast-div-00.txt>                                  
  4708.  
  4709.     This document describes the CAST5-128-CBC block cipher transform
  4710.        interface used with the IP Encapsulating Security Payload (ESP).  It
  4711.        provides a full-sized 128-bit key, with a more secure derived ini-
  4712.        tialization variable, and a more efficient smaller datagram size.   
  4713.  
  4714.   "The ESP CBC-Mode Cipher Algorithms", R. Adams, R. Pereira, 10/02/1997, 
  4715.   <draft-ietf-ipsec-ciph-cbc-00.txt>                                       
  4716.  
  4717.        This document describes how to use CBC-mode cipher algorithms with
  4718.        the IPSec ESP (Encapsulating Security Payload) Protocol.  It not
  4719.        only clearly states how to use certain cipher algorithms, but also
  4720.        how to use all CBC-mode cipher algorithms.                          
  4721.  
  4722.   "The ISAKMP Configuration Mode",, 10/02/1997, 
  4723.   <draft-ietf-ipsec-isakmp-mode-cfg-00.txt>                                
  4724.  
  4725.     This document describes a new ISAKMP mode that allows configuration
  4726.        items to be set by using both push/acknowledge and request/reply
  4727.        paradigms.                                                          
  4728.  
  4729. Integrated Services over Specific Link Layers (issll)
  4730. -----------------------------------------------------
  4731.  
  4732.   "Providing integrated services over low-bitrate links", C. Bormann, 
  4733.   07/24/1997, <draft-ietf-issll-isslow-02.txt>                             
  4734.  
  4735.     This document describes an architecture for providing integrated 
  4736.     services over low-bitrate links, such as modem lines, ISDN B-channels, 
  4737.     and sub-T1 links.  It covers only the lower parts of the Internet 
  4738.     Multimedia Conferencing Architecture [1]; additional components 
  4739.     required for application services such as Internet Telephony (e.g., a 
  4740.     session initiation protocol) are outside the scope of this document.  
  4741.     The main components of the architecture are: a real-time encapsulation 
  4742.     format for asynchronous and synchronous low-bitrate links, a header 
  4743.     compression architecture optimized for real-time flows, elements of 
  4744.     negotiation protocols used between routers (or between hosts and 
  4745.     routers), and announcement protocols used by applications to allow this
  4746.     negotiation to take place.     This document is a product of the IETF 
  4747.     ISSLL working group. Comments are solicited and should be addressed to 
  4748.     the working group's mailing list at issll@mercury.lcs.mit.edu and/or 
  4749.     the author.                                                            
  4750.  
  4751.   "Interoperation of Controlled-Load and Guaranteed-Service with ATM", M. 
  4752.   Borden, M. Garrett, 08/04/1997, <draft-ietf-issll-atm-mapping-03.txt>    
  4753.  
  4754.     Service mappings are an important aspect of effective interoperation 
  4755.     between Internet Integrated Services and ATM networks.  This document 
  4756.     provides guidelines for ATM virtual connection features and parameters 
  4757.     to be used in support of the IP integrated services protocols.  The 
  4758.     specifications include IP Guaranteed Service, Controlled-Load Service 
  4759.     and ATM Forum UNI specification, versions 3.0, 3.1 and 4.0.            
  4760.     These service mappings are intended to facilitate effective end-to-end 
  4761.     Quality of Service for IP networks containing ATM subnetworks.  We 
  4762.     discuss the various features of the IP and ATM protocols, and identify 
  4763.     solutions and difficult issues of compatibility and interoperation.    
  4764.  
  4765.   "SBM (Subnet Bandwidth Manager):  A Proposal for Admission Control over 
  4766.   IEEE 802-style networks", R. Yavatkar, Fred Baker, D. Hoffman, Y. Bernet,
  4767.   07/25/1997, <draft-ietf-issll-is802-sbm-04.txt>                          
  4768.  
  4769.     This document outlines a signaling method and protocol for RSVP-based 
  4770.     admission control over IEEE 802-style LANs.  The proposed method is 
  4771.     designed to work both with the current generation of IEEE 802 LANs and 
  4772.     new work being defined within the IEEE 802 committee.                  
  4773.  
  4774.   "A Framework for Providing Integrated Services Over Shared and Switched 
  4775.   LAN Technologies", Vijay Srinivasan, W. Pace, A. Ghanwani, 05/09/1997, 
  4776.   <draft-ietf-issll-is802-framework-02.txt>                                
  4777.  
  4778.     Traditionally, LAN technologies such as ethernet and token ring have 
  4779.     been required to handle best effort services only.  No standard 
  4780.     mechanism exists for providing service guarantees on these media as 
  4781.     will be required by emerging and future multimedia applications.  The 
  4782.     anticipated demand for such applications on the Internet has led to the
  4783.     development of RSVP, a signaling mechanism for performing resource 
  4784.     reservation in the Internet.  Concurrently, the Integrated Services 
  4785.     working group within the IETF has been working on the definition of 
  4786.     service classes called Integrated Services which are expected to make 
  4787.     use of RSVP. Applications will use these service classes in order to 
  4788.     obtain the desired quality of service from the network.  LAN 
  4789.     technologies such as token ring and ethernet typically constitute the 
  4790.     last hop in Internet connections.  It is therefore necessary to enhance
  4791.     these technologies so that they are able to support the Integrated 
  4792.     Services.  This memo describes a framework for providing the 
  4793.     functionality to support Integrated Services on shared and switched LAN
  4794.     technologies.                                                          
  4795.  
  4796.   "The Multi-Class Extension to Multi-Link PPP", C. Bormann, 07/24/1997, 
  4797.   <draft-ietf-issll-isslow-mcml-02.txt>                                    
  4798.  
  4799.     A companion document describes an architecture for providing integrated
  4800.     services over low-bitrate links, such as modem lines, ISDN B-channels, 
  4801.     and sub-T1 links [1].  The main components of the architecture are: a 
  4802.     real-time encapsulation format for asynchronous and synchronous 
  4803.     low-bitrate links, a header compression architecture optimized for 
  4804.     real-time flows, elements of negotiation protocols used between routers
  4805.     (or between hosts and routers), and announcement protocols used by 
  4806.     applications to allow this negotiation to take place.                  
  4807.     This document proposes the fragment-oriented solution for the real-time
  4808.     encapsulation format part of the architecture.  The general approach is
  4809.     to start from the PPP Multilink fragmentation protocol [2] and provide 
  4810.     a small number of extensions to add functionality and reduce the 
  4811.     overhead.   This document is a product of the IETF ISSLL working group.
  4812.     Comments are solicited and should be addressed to the two working 
  4813.     groups' mailing lists at issll@mercury.lcs.mit.edu and 
  4814.     ietf-ppp@merit.edu and/or the author.                                  
  4815.  
  4816.   "Integrated Services over IEEE 802.1D/802.1p Networks", M. Seaman, A. 
  4817.   Smith, Eric Crawley, 06/23/1997, <draft-ietf-issll-802-01.txt>           
  4818.  
  4819.     This document describes the support of IETF Integrated Services over 
  4820.     LANs built from IEEE 802 network segments which may be interconnected 
  4821.     by draft standard IEEE P802.1p switches.                               
  4822.     It describes the practical capabilities and limitations of this 
  4823.     technology for supporting Controlled Load [8] and Guaranteed Service 
  4824.     [9] using the inherent capabilities of the relevant 802 technologies 
  4825.     [5],[6] etc. and the proposed 802.1p queuing features in switches. IEEE
  4826.     P802.1p [2] is a superset of the existing IEEE 802.1D bridging 
  4827.     specification.  This document provides a functional model for the layer
  4828.     3 to layer 2 and user-to-network dialogue which supports admission 
  4829.     control and defines requirements for interoperability between switches.
  4830.     The special case of such networks where the sender and receiver are 
  4831.     located on the same segment is also discussed.       This scheme 
  4832.     expands on the ISSLL over 802 LANs framework described in [7]. It makes
  4833.     reference to an admission control signaling protocol developed by the 
  4834.     ISSLL WG which is known as the 'Subnet Bandwidth Manager'. This is an 
  4835.     extension  to the IETF's RSVP protocol [4] and is described in a 
  4836.     separate document [10].                                                
  4837.  
  4838.   "PPP in a real-time oriented HDLC-like framing", C. Bormann, 07/31/1997, 
  4839.   <draft-ietf-issll-isslow-rtf-01.txt>                                     
  4840.  
  4841.        A companion document describes an architecture for providing
  4842.        integrated services over low-bitrate links, such as modem lines, 
  4843.     ISDN
  4844.        B-channels, and sub-T1 links [1].  The main components of the
  4845.        architecture are: a real-time encapsulation format for asynchronous
  4846.        and synchronous low-bitrate links, a header compression architecture
  4847.        optimized for real-time flows, elements of negotiation protocols 
  4848.     used
  4849.        between routers (or between hosts and routers), and announcement
  4850.        protocols used by applications to allow this negotiation to take
  4851.        place.
  4852.      
  4853.        This document proposes the suspend/resume-oriented solution for the
  4854.        real-time encapsulation format part of the architecture.  The 
  4855.     general
  4856.        approach is to start from the PPP Multilink fragmentation protocol
  4857.        [2] and its multi-class extension [5] and add suspend/resume in a 
  4858.     way
  4859.        that is as compatible to existing hard- and firmware as possible.
  4860.      
  4861.        This document is a product of the IETF ISSLL working group.
  4862.        Comments are solicited and should be addressed to the two working
  4863.        groups' mailing lists at issll@mercury.lcs.mit.edu and ietf-
  4864.        ppp@merit.edu and/or the author.
  4865.                                                                            
  4866.  
  4867.   "Network Element Service Specification for Low Speed Networks", S. 
  4868.   Jackowski, 05/12/1997, <draft-ietf-issll-isslow-svcmap-00.txt>           
  4869.  
  4870.     This document defines the service mappings for controlled load and 
  4871.     guaranteed services over low-bitrate networks.  These low bitrate 
  4872.     networks typically include components such as analog lines, ISDN 
  4873.     connections and sub-T1 rate links. The document specifies the 
  4874.     per-network element packet handling behavior, parameters required, 
  4875.     traffic specification, policing requirements, and traffic ordering 
  4876.     relationships which are required to provide both Guaranteed and 
  4877.     Controlled Load service capabilities.  It also includes evaluation 
  4878.     criteria for elements providing the service.           This document is
  4879.     a product of the IETF ISSL working group and is based on [1] and [2] 
  4880.     which describe modifications to the PPP protocol to enable these 
  4881.     services.                                                              
  4882.  
  4883.   "RSVP over ATM Implementation Requirements", Lou Berger, 07/11/1997, 
  4884.   <draft-ietf-issll-atm-imp-req-00.txt, .ps>                               
  4885.  
  4886.     This note presents specific implementation requirements for running 
  4887.     RSVP over ATM switched virtual circuits (SVCs).  It presents 
  4888.     requirements that ensure interoperability between multiple 
  4889.     implementations and conformance to the RSVP and Integrated Services 
  4890.     specifications.  A separate document [6] provides specific guidelines 
  4891.     for running over today's ATM networks.  The general problem is 
  4892.     discussed in [11].   Integrated Services to ATM service mappings are 
  4893.     covered in [9].  The full set of documents present the background and 
  4894.     information needed to implement Integrated Services and RSVP over ATM. 
  4895.  
  4896.   "A Framework for Integrated Services and RSVP over ATM", M. Borden, John 
  4897.   Krawczyk, Lou Berger, Eric Crawley, 07/24/1997, 
  4898.   <draft-ietf-issll-atm-framework-00.txt>                                  
  4899.  
  4900.     This document outlines the framework and issues related to providing IP
  4901.     Integrated Services with RSVP over ATM. It provides an overall approach
  4902.     to the problem(s) and related issues.  These issues and problems are to
  4903.     be addressed in further documents from the ISATM subgroup of the ISSLL 
  4904.     working group.                                                         
  4905.     Editor's Note                                                          
  4906.     This document is the merger of two previous documents, 
  4907.     draft-ietf-issll-atm-support-02.txt by Berger and Berson and 
  4908.     draft-crawley-rsvp-over-atm-00.txt by Baker, Berson, Borden, Crawley, 
  4909.     and Krawczyk.  The former document has been split into this document 
  4910.     and a set of documents on RSVP over ATM implementation requirements and
  4911.     guidelines.                                                            
  4912.  
  4913.   "Integrated Service Mappings on IEEE 802 Networks", M. Seaman, A. Smith, 
  4914.   Eric Crawley, 07/30/1997, <draft-ietf-issll-is802-svc-mapping-00.txt>    
  4915.  
  4916.     This document describes the support of IETF Integrated Services over
  4917.     LANs built from IEEE 802 network segments which may be interconnected 
  4918.     by
  4919.     IEEE 802.1 MAC Bridges (switches) [1].
  4920.     
  4921.     It describes the practical capabilities and limitations of this
  4922.     technology for supporting Controlled Load [8] and Guaranteed Service 
  4923.     [9]
  4924.     using the inherent capabilities of the relevant 802 technologies
  4925.     [5],[6],[15],[16] etc. and the proposed 802.1p queuing features in
  4926.     switches. IEEE P802.1p [2] is a superset of the existing IEEE 802.1D
  4927.     bridging specification. This document provides a functional model for
  4928.     the layer 3 to layer 2 and user-to-network dialogue which supports
  4929.     admission control and defines requirements for interoperability between
  4930.     switches. The special case of such networks where the sender and
  4931.     receiver are located on the same segment is also discussed.
  4932.     
  4933.     This scheme expands on the ISSLL over 802 LANs framework described in
  4934.     [7]. It makes reference to a signaling protocol for admission control
  4935.     developed by the ISSLL WG which is known as the 'Subnet Bandwidth
  4936.     Manager'. This is an extension  to the IETF's RSVP protocol [4] and is
  4937.     described in a separate document [10].                                 
  4938.  
  4939. Large Scale Multicast Applications (lsma)
  4940. -----------------------------------------
  4941.  
  4942.   "Scenarios and Appropriate Protocols for Distributed Interactive 
  4943.   Simulation", Michael Myjak, W. Smith, S. Seidensticker, 07/21/1997, 
  4944.   <draft-ietf-lsma-scenarios-01.txt>                                       
  4945.  
  4946.     We describe distributed interactive simulation (DIS) scenarios from the
  4947.     vantage point of hardware and software vendors who would need to 
  4948.     address the network implications and requirements to enable large scale
  4949.     networked multiplayer virtual worlds. This document is meant to migrate
  4950.     the knowledge of the traditional Department of Defense (DoD) modeling 
  4951.     and simulation community into tangible design metrics for the 
  4952.     commercial networking community [2]. [Note: The term 'DIS' is used here
  4953.     generically to describe the type of simulations used to implement these
  4954.     scenarios. It does not imply the use of IEEE 1278.1 protocols[1], 
  4955.     frequently referred to as DIS protocols.]                              
  4956.  
  4957.   "Limitations of Internet Protocol Suite for Distributed Simulation in the
  4958.   Large Multicast Environment", Mark Pullen, Michael Myjak, C. Bouwens, 
  4959.   03/26/1997, <draft-ietf-lsma-limitations-01.txt>                         
  4960.  
  4961.     The Large-Scale Multicast Applications (LSMA) working group was 
  4962.     chartered to produce two Internet-Drafts aimed at a consensus-based 
  4963.     development of the Internet protocols to support large scale, real-time
  4964.     distributed simulation.  This draft defines aspects of the Internet 
  4965.     protocols that LSMA has found may need further development in order to 
  4966.     meet that goal.                                                        
  4967.  
  4968.   "Taxonomy of Communication Requirements for Large-scale Multicast 
  4969.   Applications", P Bagnall, B Briscoe, 07/30/1997, 
  4970.   <draft-ietf-lsma-requirements-00.txt>                                    
  4971.  
  4972.     The intention of this draft is to define a classification system for 
  4973.     the
  4974.     communication requirements of any large-scale multicast application
  4975.     (LSMA). It is very unlikely one protocol can achieve a compromise
  4976.     between the diverse requirements of all the parties involved in any
  4977.     LSMA. It is therefore necessary to understand the worst-case scenarios
  4978.     in order to minimise the range of protocols needed. Dynamic protocol
  4979.     adaptation is likely to be necessary which will require logic to map
  4980.     particular combinations of requirements to particular mechanisms.
  4981.     Standardising the way that applications define their requirements is a
  4982.     necessary step towards this. Classification is a first step towards
  4983.     standardisation.                                                       
  4984.  
  4985. Mail and Directory Management (madman)
  4986. --------------------------------------
  4987.  
  4988.   "Mail Monitoring MIB", Steve Kille, Ned Freed, 08/20/1997, 
  4989.   <draft-ietf-madman-mail-monitor-mib-05.txt>                              
  4990.  
  4991.     This memo defines a portion of the Management Information Base (MIB) 
  4992.     for
  4993.     use with network management protocols in the Internet community.
  4994.     Specifically, this memo extends the basic Network Services Monitoring
  4995.     MIB [8] to allow monitoring of Message Transfer Agents (MTAs). It may
  4996.     also be used to monitor MTA components within gateways.                
  4997.  
  4998.   "Network Services Monitoring MIB", Steve Kille, Ned Freed, 08/20/1997, 
  4999.   <draft-ietf-madman-nsm-mib-06.txt>                                       
  5000.  
  5001.     A networked application is a realization of some well defined service 
  5002.     on
  5003.     one or more host computers that is accessible via some network, uses
  5004.     some network for its internal operations, or both.                     
  5005.  
  5006.   "Directory Server Monitoring MIB", Steve Kille, Glenn Mansfield, 
  5007.   08/02/1997, <draft-ietf-madman-dsa-mib-1-04.txt>                         
  5008.  
  5009.     This memo defines a portion of the Management Information Base (MIB)
  5010.        for use with network management protocols in the Internet community.
  5011.        Specifically, this memo extends the basic Network Services 
  5012.     Monitoring
  5013.        MIB [9] to allow monitoring of Directory Servers.                   
  5014.  
  5015.   "Message Tracking MIB", Gordon Jones, 08/21/1997, 
  5016.   <draft-ietf-madman-trackmib-00.txt>                                      
  5017.  
  5018.     This document defines a message tracking Management Information Base
  5019.     (MIB) for electronic messaging usage. Message tracking is the ability 
  5020.     to find out, after the fact, the path that a particular message took 
  5021.     through the messaging system and the current status of that message.   
  5022.  
  5023. Mobile Ad-hoc Networks (manet)
  5024. ------------------------------
  5025.  
  5026.   "Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues 
  5027.   and Evaluation Considerations", Joseph Macker, Scott Corson, 09/15/1997, 
  5028.   <draft-ietf-manet-issues-00.txt>                                         
  5029.  
  5030.     This memo describes the concept of mobile ad hoc networking--giving a
  5031.     rationale for its existence and outlining the unique issues and
  5032.     challenges found in this form of purely wireless, mobile networking.   
  5033.  
  5034.   "Mobile Ad Hoc Networking Terminology", C. Perkins, 10/31/1997, 
  5035.   <draft-ietf-manet-term-00.txt>                                           
  5036.  
  5037.        This document presents conventional definitions for many terms to be
  5038.        used during the discussion of various algorithms for enabling ad hoc
  5039.        networks of mobile computers, particularly over wireless media.
  5040.                                                                            
  5041.  
  5042. MBONE Deployment (mboned)
  5043. -------------------------
  5044.  
  5045.   "Multicast pruning a necessity", J. Hawkinson, 08/04/1997, 
  5046.   <draft-ietf-mboned-pruning-02.txt>                                       
  5047.  
  5048.        This document calls for the MBone to be free of non-pruning 
  5049.     multicast
  5050.        as soon as possible, due to the high cost to the Internet of the
  5051.        traffic resulting from them. Consensus is that [DATE 1 month from 
  5052.     RFC
  5053.        publication] is the goal date for elimating non-pruning multicast
  5054.        routers.
  5055.      
  5056.        It cites several ways to eliminate non-pruning multicast from a
  5057.        network, allowing per-site flexibility.                             
  5058.  
  5059.   "Administratively Scoped IP Multicast", David Meyer, 06/10/1997, 
  5060.   <draft-ietf-mboned-admin-ip-space-03.txt>                                
  5061.  
  5062.     This document defines the 'administratively scoped IPv4 multicast 
  5063.     space' to be the range 239.0.0.0 to 239.255.255.255. In addition, it 
  5064.     describes a simple set of semantics for the implementation of 
  5065.     Administratively Scoped IP Multicast. Finally, it provides a mapping 
  5066.     between the IPv6 multicast address classes [RFC1884] and IPv4 multicast
  5067.     address classes.              This memo is a product of the MBONE 
  5068.     Deployment Working Group (MBONED) in the Operational Requirements area 
  5069.     of the Internet Engineering Task Force. Submit comments to 
  5070.     <mboned@ns.uoregon.edu> or the author.                                 
  5071.  
  5072.   "Introduction to IP Multicast Routing", T. Maufer, C. Semeria, 
  5073.   10/28/1997, <draft-ietf-mboned-intro-multicast-03.txt>                   
  5074.  
  5075.     The first part of this paper describes the benefits of multicasting,
  5076.     the MBone, Class D addressing, and the operation of the Internet Group
  5077.     Management Protocol (IGMP).  The second section explores a number of
  5078.     different techniques that may potentially be employed by multicast
  5079.     routing protocols:
  5080.      
  5081.         o  Flooding
  5082.         o  Spanning Trees
  5083.         o  Reverse Path Broadcasting (RPB)
  5084.         o  Truncated Reverse Path Broadcasting (TRPB)
  5085.         o  Reverse Path Multicasting (RPM)
  5086.         o  ''Shared-Tree'' Techniques
  5087.      
  5088.     The third part contains the main body of the paper.  It describes how
  5089.     the previous techniques are implemented in multicast routing protocols
  5090.     available today (or under development).
  5091.      
  5092.         o  Distance Vector Multicast Routing Protocol (DVMRP)
  5093.         o  Multicast Extensions to OSPF (MOSPF)
  5094.         o  Protocol-Independent Multicast - Dense Mode (PIM-DM)
  5095.         o  Protocol-Independent Multicast - Sparse Mode (PIM-SM)
  5096.         o  Core-Based Trees (CBT)                                          
  5097.  
  5098.   "Some Issues for an Inter-domain Multicast Routing Protocol", David 
  5099.   Meyer, 06/10/1997, <draft-ietf-mboned-imrp-some-issues-02.txt>           
  5100.  
  5101.     The IETF's Inter-Domain Multicast Routing (IDMR) working group has 
  5102.     produced several multicast routing protocols, including Core Based 
  5103.     Trees [CBT] and Protocol Independent Multicasting [PIMARCH]. In 
  5104.     addition, the IDMR WG has formalized the specification of the Distance 
  5105.     Vector Multicast Routing Protocol [DVMRP]. Various specifications for 
  5106.     protocol inter-operation have also been produced (see, for example, 
  5107.     [THALER96] and [PIMMBR]). However, none of these protocols seems 
  5108.     ideally suited to the inter-domain routing case; that is, while these 
  5109.     protocols are appropriate for the intra-domain routing environment, 
  5110.     they break down in various ways when applied in to the multi-provider 
  5111.     inter-domain case.                   This document considers some of 
  5112.     the scaling, stability and policy issues that are of primary importance
  5113.     in a inter-domain, multi-provider multicast environment.               
  5114.  
  5115.   "Guidelines for Rate Limits on the MBONE", D. Junkins, 02/19/1997, 
  5116.   <draft-ietf-mboned-limit-rate-guide-00.txt>                              
  5117.  
  5118.     Much confusion and misunderstanding exists in the Internet community on
  5119.     the use of rate limits on the Multicast Backbone (MBONE).  This 
  5120.     document dispels some of the misunderstandings of rate limits and 
  5121.     describes the best current practices for when to implement rate limits 
  5122.     on MBONE links.   It is a product of the Multicast Deployment Working 
  5123.     Group in the Operational Requirements area of the Internet Engineering 
  5124.     Task Force. Submit comments to <mboned@ns.uoregon.edu> or the author.  
  5125.  
  5126.   "PIM Multicast Border Router (PMBR) specification for connecting  PIM-SM 
  5127.   domains to a DVMRP Backbone", Deborah Estrin, D. Thaler, A. Helmy, 
  5128.   02/24/1997, <draft-ietf-mboned-pmbr-spec-00.txt, .ps>                    
  5129.  
  5130.     This document specifies the behavior of PIM-SM Multicast Border Routers
  5131.     (PMBRs) that connect PIM-SM to DVMRP networks. We assume that the 
  5132.     reader is familiar with the PIM-SM protocol specification.[Estrin96]   
  5133.  
  5134.   "Multicast Debugging Handbook", B. Aboba, D. Thaler, 03/26/1997, 
  5135.   <draft-ietf-mboned-mdh-00.txt>                                           
  5136.  
  5137.     This document serves as a handbook for the debugging of multicast 
  5138.     connectivity problems. In  addition  to  reviewing  commonly  
  5139.     encountered problems,  the draft summarizes publicly distributable 
  5140.     multicast dianostic tools, and provides examples of their use, along 
  5141.     with  pointers to source and binary distributions.                     
  5142.  
  5143. MIME Encapsulation of Aggregate HTML Documents (mhtml)
  5144. ------------------------------------------------------
  5145.  
  5146.   "Sending HTML in E-mail, an informational supplement to RFC ???: MIME 
  5147.   E-mail Encapsulation of Aggregate HTML Documents (MHTML)", J. Palme, 
  5148.   07/21/1997, <draft-ietf-mhtml-info-06.txt>                               
  5149.  
  5150.     The memo 'MIME E-mail Encapsulation of Aggregate HTML Documents 
  5151.     (MHTML)' (draft-ietf-mhtml-spec-04.txt) specifies how to send packaged 
  5152.     aggregate HTML objects in MIME e-mail. This memo is an accompanying 
  5153.     informational document, intended to be an aid to developers. This 
  5154.     document is not an Internet standard.                                  
  5155.     Issues discussed are implementation methods, caching strategies, 
  5156.     problems with rewriting of URIs, making messages suitable both for 
  5157.     mailers which can and which cannot handle Multipart/related and 
  5158.     handling recipients which do not have full Internet connectivity.      
  5159.  
  5160.   "MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)", A. 
  5161.   Hopmann, J. Palme, 10/27/1997, <draft-ietf-mhtml-rev-02.txt>             
  5162.  
  5163.        Although HTML [RFC 1866] was designed within the context of MIME,
  5164.        more than the specification of HTML as defined in RFC 1866 is needed
  5165.        for two electronic mail user agents to be able to interoperate using
  5166.        HTML as a document format. These issues include the naming of
  5167.        objects that are normally referred to by URIs, and the means of
  5168.        aggregating objects that go together. This document describes a set
  5169.        of guidelines that will allow conforming mail user agents to be able
  5170.        to send, deliver and display these objects, such as HTML objects,
  5171.        that can contain links represented by URIs. In order to be able to
  5172.        handle inter-linked objects, the document uses the MIME type
  5173.        ''multipart/related'' and specifies the MIME content-headers
  5174.        ''Content-Location'' and ''Content-Base''. The guidelines in this
  5175.        document can also be used when sending aggregate HTML objects in
  5176.        other forms than e-mail, such as through HTTP or FTP.
  5177.      
  5178.        Differences compared to the previous version of this proposed
  5179.        standard, published in RFC 2110, are summarized in chapter 13.      
  5180.  
  5181.   "Content-ID and Message-ID Uniform Resource Locators", Ed Levinson, 
  5182.   07/25/1997, <draft-ietf-mhtml-cid-v2-00.txt>                             
  5183.  
  5184.     The Uniform Resource Locator (URL) schemes, 'cid:' and 'mid:' allow 
  5185.     references to messages and the body parts of messages.  For example, 
  5186.     within a single multipart message, one HTML body part might include 
  5187.     embedded references to other parts of the same message.                
  5188.  
  5189.   "The MIME Multipart/Related Content-type",, 09/09/1997, 
  5190.   <draft-ietf-mhtml-rel-v2-00.txt>                                         
  5191.  
  5192.        The Multipart/Related content-type provides a common mechanism for
  5193.        representing objects that are aggregates of related MIME body parts.
  5194.        This document defines the Multipart/Related content-type and 
  5195.     provides
  5196.        examples of its use.                                                
  5197.  
  5198. MIME - X.400 Gateway (mixer)
  5199. ----------------------------
  5200.  
  5201.   "MIXER (Mime Internet X.400 Enhanced Relay):  Mapping between X.400 and 
  5202.   RFC 822/MIME", Steve Kille, 03/20/1997, 
  5203.   <draft-kille-mixer-rfc1327bis-05.txt>                                    
  5204.  
  5205.     This document relates primarily to the ITU-T 1988 and 1992 X.400 Series
  5206.     Recommendations / ISO IEC 10021 International Standard.  This ISO/ITU-T
  5207.     standard is referred to in this document as 'X.400', which is a 
  5208.     convenient shorthand.  Any reference to the 1984 Recommendations will 
  5209.     be explicit.  Any mappings relating to elements which are in the 1992 
  5210.     version and not in the 1988 version will be noted explicitly.  X.400 
  5211.     defines an Interpersonal Messaging System (IPMS), making use of a store
  5212.     and forward Message Transfer System.  This document relates to the 
  5213.     IPMS, and not to wider application of X.400, such as EDI as defined in 
  5214.     X.435.                                                                 
  5215.  
  5216.   "Mapping between X.400 and RFC-822/MIME Message Bodies", Harald 
  5217.   Alvestrand, 04/30/1997, <draft-ietf-mixer-bodymap-07.txt>                
  5218.  
  5219.     This document is a companion to [MIXER], which defines the principles 
  5220.     and translation of headers for interworking between MIME-based RFC-822 
  5221.     mail and X.400 mail.           This document defines how to map body 
  5222.     parts of X.400 messages into MIME entities and vice versa, including 
  5223.     the handling of multipart messages and forwarded messages.             
  5224.     A table of contents that should be quite useful for locating specific 
  5225.     sections is given in the back of the document.                         
  5226.  
  5227.   "X.400 image body parts", Harald Alvestrand, 09/16/1996, 
  5228.   <draft-ietf-mixer-images-01.txt>                                         
  5229.  
  5230.     This document contains the body parts defined in RFC 1495 for carrying 
  5231.     image formats that were originally defined in MIME through an X.400 
  5232.     system.                                                                
  5233.     This document is an Experimental standard; if it turns out to be useful
  5234.     and widely deployed, it can be moved onto the standards track.         
  5235.     It also documents the OIDs assigned to these data formats as FTAM body 
  5236.     parts, which allow the MIME types to be converted to FTAM body parts; 
  5237.     this will probably be more useful than the new body parts defined here.
  5238.  
  5239.   "A MIME body part for FAX", Harald Alvestrand, 02/20/1997, 
  5240.   <draft-ietf-mixer-fax-01.txt>                                            
  5241.  
  5242.     This document contains the definitions, originally contained in RFC 
  5243.     1494, on how to carry CCITT G3Fax in MIME, and how to translate it to 
  5244.     its X.400 representation.                                              
  5245.     This document is an Experimental standard; if it turns out to be useful
  5246.     and widely deployed, it can be moved onto the standards track.         
  5247.     NOTE: At the moment, this format does not seem appropriate for a 
  5248.     'general purpose image format for the Internet', if such a beast can 
  5249.     exist. It exists only to carry information that is already in G3 Fax 
  5250.     format, and may be usefully converted to other formats when used in 
  5251.     specific contexts.                                                     
  5252.  
  5253.   "A MIME body part for ODA", Harald Alvestrand, 02/20/1997, 
  5254.   <draft-ietf-mixer-oda-01.txt>                                            
  5255.  
  5256.     This document contains the definitions, originally contained in RFC 
  5257.     1495 and RFC 1341, on how to carry ODA in MIME, and how to translate it
  5258.     to its X.400 representation.                                           
  5259.     This document is an Experimental standard; if it turns out to be useful
  5260.     and widely deployed, it can be moved onto the standards track.         
  5261.  
  5262.   "Carrying PostScript in X.400 and MIME", Harald Alvestrand, 02/20/1997, 
  5263.   <draft-ietf-mixer-postscript-01.txt>                                     
  5264.  
  5265.     This document describes methods for carrying PostScript information in 
  5266.     the two standard mail systems MIME and X.400, and the conversion 
  5267.     between them. It uses the notational conventions of [BODYMAP], and the 
  5268.     conversion is further described in [MIXER].                            
  5269.     Two ways of carrying PostScript in X.400 are described.                
  5270.     One is using the FTAM Body Part, and one uses the Extended Body Part 
  5271.     originally described in RFC 1494.                                      
  5272.     The FTAM method is recommended.                                        
  5273.  
  5274.   "Using the Internet DNS to Distribute MIXER Conformant Global Address 
  5275.   Mapping (MCGAM)", C. Allocchio, 07/11/1997, 
  5276.   <draft-ietf-mixer-rfc1664bis-01.txt>                                     
  5277.  
  5278.     This memo is the complete technical specification to store in the 
  5279.     Internet Domain Name System (DNS) the mapping information (MCGAM) 
  5280.     needed by MIXER conformant e-mail gateways and other tools to map 
  5281.     RFC822 domain names into X.400 O/R names and vice versa.  Mapping 
  5282.     information can be managed in a distributed rather than a centralised 
  5283.     way. Organizations can publish their MIXER mapping or preferred gateway
  5284.     routing information using just local resources (their local DNS 
  5285.     server), avoiding the need for a strong coordination with any 
  5286.     centralised organization. MIXER conformant gateways and tools located 
  5287.     on Internet hosts can retrieve the mapping information querying the DNS
  5288.     instead of having fixed tables which need to be centrally updated and 
  5289.     distributed.    This memo obsoletes RFC1664. It includes the changes 
  5290.     introduced by MIXER specification with respect to RFC1327: the new 
  5291.     'gate1' (O/R addresses to domain) table is fully supported. Full 
  5292.     backward compatibility with RFC1664 specification is mantained, too.   
  5293.     RFC1664 was a joint effort of IETF X400 operation working group 
  5294.     (x400ops) and TERENA (formely named 'RARE') Mail and Messaging working 
  5295.     group (WG-MSG). This update was performed by the IETF MIXER working 
  5296.     group.                                                                 
  5297.  
  5298.   "MaXIM-11 - Mapping between X.400 / Internet mail and Mail-11 mail", C. 
  5299.   Allocchio, 01/31/1997, <draft-ietf-mixer-mail11-00.txt>                  
  5300.  
  5301.     This document describes a set of mappings which will enable inter 
  5302.     working between systems operating the ISO/IEC 10021 - CCITT (now ITU) 
  5303.     X.400 Recommendations on Message Handling Systems, and systems running 
  5304.     the Mail-11 (also known as DECnet mail or VMSmail) protocol.  The 
  5305.     specifications are valid both within DECnet Phase IV and DECnet/OSI 
  5306.     addressing and routing scheme.                                         
  5307.     The complete scenario of X.400 / MIME / Mail-11 is also considered, in 
  5308.     order to cover the possible complex cases arising in multiple gateway 
  5309.     translations.                                                          
  5310.     This document covers mainly the X.400 O/R address to/from Mail-11 
  5311.     address mapping and the RFC822 to/from Mail-11 ones; other mappings are
  5312.     based on MIXER specifications. Bodypart mappings are not specified in 
  5313.     this document: MIXER and MIME-MHS specifications can be applied to map 
  5314.     bodyparts between X.400, MIME and Mail-11, too. In fact MIME encoding 
  5315.     can be used without modifications within Mail-11 text bodyparts.   This
  5316.     document obsoletes RFC 1405, which was a combined effort of TERENA 
  5317.     Working Group on Messaging, and the IETF X.400 Ops Working Group.      
  5318.  
  5319.   "Use of an X.500/LDAP directory to support MIXER address mapping", Steve 
  5320.   Kille, 07/16/1997, <draft-ietf-mixer-directory-02.txt>                   
  5321.  
  5322.     This document defines how to use an X.500 or LDAP directory to support 
  5323.     the mapping between X.400 OR Addresses and mailboxes defined in MIXER 
  5324.     (RFC 1327bis) [5].                                                     
  5325.     This draft document will be submitted to the RFC editor as a protocol 
  5326.     standard.  Distribution of this memo is unlimited.                     
  5327.  
  5328.   "Representing Tables and Subtrees in the X.500 Directory",, 08/29/1997, 
  5329.   <draft-ietf-mixer-subtrees-00.txt>                                       
  5330.  
  5331.     This document defines techniques for representing two types of
  5332.     information mapping in the OSI Directory [1].
  5333.      
  5334.      
  5335.     1.  Mapping from a key to a value (or set of values), as might be done
  5336.         in a table lookup.
  5337.      
  5338.     2.  Mapping from a distinguished name to an associated value (or
  5339.         values), where the values are not defined by the owner of the
  5340.         entry.  This is achieved by use of a directory subtree.            
  5341.  
  5342.   "Representing the O/R Address hierarchy in the X.500 Directory 
  5343.   Information Tree",, 08/29/1997, <draft-ietf-mixer-infotree-00.txt>       
  5344.  
  5345.     This document defines a representation of the O/R Address hierarchy in
  5346.     the Directory Information Tree [6, 1].  This is useful for a range of
  5347.     purposes, including:
  5348.      
  5349.      
  5350.      o  Support for MHS Routing [4].
  5351.      
  5352.      o  Support for X.400/RFC 822 address mappings [2, 5].
  5353.      
  5354.     This draft document will be submitted to the RFC editor as a protocol
  5355.     standard.  Distribution of this memo is unlimited.  Please send
  5356.     comments to the author or to the discussion group
  5357.     <mhs-ds@mercury.udev.cdc.com>.                                         
  5358.  
  5359. Multiparty Multimedia Session Control (mmusic)
  5360. ----------------------------------------------
  5361.  
  5362.   "SDP: Session Description Protocol", V. Jacobson, Mark Handley, 
  5363.   09/09/1997, <draft-ietf-mmusic-sdp-04.txt,.ps>                           
  5364.  
  5365.     This document defines the Session Description  Protocol,  SDP.
  5366.     SDP  is  intended  for  describing multimedia sessions for the
  5367.     purposes of  session  announcement,  session  invitation,  and
  5368.     other forms of multimedia session initiation.
  5369.       
  5370.     This document is a product of the Multiparty Multimedia Session  
  5371.     Control
  5372.     (MMUSIC) working group of the Internet Engineering Task Force.  
  5373.     Comments
  5374.     are solicited and should be addressed to  the  working  group's  
  5375.     mailing
  5376.     list at confctrl@isi.edu and/or the authors.
  5377.                                                                            
  5378.  
  5379.   "Real Time Streaming Protocol (RTSP)", H. Schulzrinne, A. Rao, R. 
  5380.   Lanphier, 10/29/1997, <draft-ietf-mmusic-rtsp-05.txt,.ps>                
  5381.  
  5382.     The Real Time Streaming Protocol, or RTSP, is an application-level
  5383.        protocol for control over the delivery of data with real-time
  5384.        properties. RTSP provides an extensible framework to enable
  5385.        controlled, on-demand delivery of real-time data, such as audio and
  5386.        video. Sources of data can include both live data feeds and stored
  5387.        clips. This protocol is intended to control multiple data delivery
  5388.        sessions, provide a means for choosing delivery channels such as 
  5389.     UDP,
  5390.        multicast UDP and TCP, and provide a means for choosing delivery
  5391.        mechanisms based upon RTP (RFC 1889).
  5392.      
  5393.        This is a snapshot of the current draft which will become the next
  5394.        version of the ``official'' Internet Draft.                         
  5395.  
  5396.   "SIP: Session Initiation Protocol", Eve Schooler, H. Schulzrinne, Mark 
  5397.   Handley, 08/02/1997, <draft-ietf-mmusic-sip-03.txt,.ps>                  
  5398.  
  5399.     Many styles of multimedia conferencing are likely to co-exist on the 
  5400.     Internet, and many of them share the need to invite users to 
  5401.     participate. The Session Initiation Protocol (SIP) is a simple protocol
  5402.     designed to enable the invitation of users to participate in such 
  5403.     multimedia sessions. It is not tied to any specific conference control 
  5404.     scheme, providing support for either loosely or tightly controlled 
  5405.     sessions. In particular, it aims to enable user mobility by relaying 
  5406.     and redirecting invitations to a user's current location.             
  5407.     This document is a product of the Multiparty Multimedia Session Control
  5408.     (MMUSIC) working group of the Internet Engineering Task Force.  
  5409.     Comments are solicited and should be addressed to the working group's 
  5410.     mailing list at confctrl@isi.edu and/or the authors.                   
  5411.  
  5412.   "Specification of Security in SAP Using Public Key Algorithms", Peter 
  5413.   Kirstein, G. Montasser-Kohsari, E. Whelan, 10/28/1997, 
  5414.   <draft-ietf-mmusic-sap-sec-03.txt,.ps>                                   
  5415.  
  5416.     The Session Announcement Protocol (SAP) has been specified in such a 
  5417.     way
  5418.     that authentication and privacy can be assured. However the algorithms
  5419.     and mechanisms to achieve such security are not prescribed in the
  5420.     current draft. This document extends the SAP protocol, by describing
  5421.     specific algorithms and formats of authentication and encryption 
  5422.     formats
  5423.     based on PGP and PKCS#7 standards. It is a companion document to
  5424.     draft-ietf-mmusic-sap.
  5425.      
  5426.     This document is a product of the Multiparty Multimedia Session Control
  5427.     (MMUSIC) working group of the Internet Engineering Task Force Comments
  5428.     are solicited and should be addressed to the working group's mailing
  5429.     list at confctrl@isi.edu and/or the authors.                           
  5430.  
  5431.   "SIP URL Scheme", H. Schulzrinne, 05/14/1997, 
  5432.   <draft-ietf-mmusic-sip-url-00.txt, .ps>                                  
  5433.  
  5434.     A family of new URL schemes, 'sip*:', is defined. It is used to 
  5435.     establish multimedia conferences using the Session Initiation Protocol 
  5436.     (SIP).                                                                 
  5437.  
  5438.   "The Internet Multimedia Conferencing Architecture", Jon Crowcroft, Mark 
  5439.   Handley, Joerg Ott, C. Bormann, 09/09/1997, 
  5440.   <draft-ietf-mmusic-confarch-00.txt>                                      
  5441.  
  5442.        This document provides an overview of multimedia conferencing on the
  5443.        Internet.  The protocols mentioned are specified elsewhere as RFCs,
  5444.        Internet-Drafts, or ITU recommendations.  Each of these
  5445.        specifications gives details of the protocol itself, how it works 
  5446.     and
  5447.        what it does.  This document attempts to provide the reader with an
  5448.        overview of how the components fit together and of some of the
  5449.        assumptions made, as well as some statement of direction for those
  5450.        components still in a nascent stage.
  5451.      
  5452.        This document is a product of the Multiparty Multimedia Session
  5453.        Control (MMUSIC) working group of the Internet Engineering Task
  5454.        Force.  Comments are solicited and should be addressed to the 
  5455.     working
  5456.        group's mailing list at confctrl@isi.edu and/or the authors.        
  5457.  
  5458. IP Routing for Wireless/Mobile Hosts (mobileip)
  5459. -----------------------------------------------
  5460.  
  5461.   "Route Optimization in Mobile IP", C. Perkins, D. Johnson, 08/04/1997, 
  5462.   <draft-ietf-mobileip-optim-06.txt>                                       
  5463.  
  5464.     This document defines extensions to the operation of the base Mobile IP
  5465.     protocol to allow for optimization of datagram routing from a 
  5466.     correspondent node to a mobile node.  Without Route Optimization, all 
  5467.     datagrams destined to a mobile node are routed through that mobile 
  5468.     node's home agent, which then tunnels each datagram to the mobile 
  5469.     node's current location.  The protocol extensions described here 
  5470.     provide a means for correspondent nodes that implement them to cache 
  5471.     the binding of a mobile node and to then tunnel their own datagrams for
  5472.     the mobile node directly to that location, bypassing the possibly 
  5473.     lengthy route for each datagram to and from the mobile node's home 
  5474.     agent.  Extensions are also provided to allow datagrams in flight when 
  5475.     a mobile node moves, and datagrams sent based on an out-of-date cached 
  5476.     binding, to be forwarded directly to the mobile node's new binding.    
  5477.  
  5478.   "Mobility Support in IPv6", C. Perkins, D. Johnson, 08/01/1997, 
  5479.   <draft-ietf-mobileip-ipv6-03.txt>                                        
  5480.  
  5481.     This document specifies the operation of mobile computers using IPv6.
  5482.        Each mobile node is always identified by its home address, 
  5483.     regardless
  5484.        of its current point of attachment to the Internet.  While situated
  5485.        away from its home, a mobile node is also associated with a care-of
  5486.        address, which provides information about the mobile node's current
  5487.        location.  IPv6 packets addressed to a mobile node's home address 
  5488.     are
  5489.        transparently routed to its care-of address.  The protocol enables
  5490.        IPv6 nodes to cache the binding of a mobile node's home address with
  5491.        its care-of address, and to then send packets destined for the 
  5492.     mobile
  5493.        node directly to it at this care-of address.                        
  5494.  
  5495.   "Firewall Traversal for Mobile IP: Goals and Requirements", S. Glass, V. 
  5496.   Gupta, 01/24/1997, <draft-ietf-mobileip-ft-req-00.txt>                   
  5497.  
  5498.     This document discusses problems arising out of the use of Mobile IP in
  5499.     a security conscious Internet and presents a list of solution 
  5500.     requirements deemed important. These problems may need to be resolved 
  5501.     in several stages. A priority order in which these problems should be 
  5502.     solved is also proposed.                                               
  5503.     All firewalls are assumed to implement standard mechanisms [RFCs 
  5504.     1825,1826,1827] for authentication and encryption proposed by the IPSec
  5505.     working group of the IETF.                                             
  5506.  
  5507.   "Reverse Tunneling for Mobile IP", G. Montenegro, 08/20/1997, 
  5508.   <draft-ietf-mobileip-tunnel-reverse-04.txt>                              
  5509.  
  5510.     Mobile IP uses tunneling from the home agent to the mobile node's
  5511.        care-of address, but rarely in the reverse direction.  Usually, a
  5512.        mobile node sends its packets through a router on the foreign
  5513.        network, and assumes that routing is independent of source address.
  5514.        When this assumption is not true, it is convenient to establish a
  5515.        topologically correct reverse tunnel from the care-of address to the
  5516.        home agent.
  5517.      
  5518.        This document proposes backwards-compatible extensions to Mobile IP
  5519.        in order to support topologically correct reverse tunnels.  This
  5520.        document does not attempt to solve the problems posed by firewalls
  5521.        located between the home agent and the mobile node's care-of
  5522.        address.                                                            
  5523.  
  5524.   "Firewall Traversal for Mobile IP: Guidelines for Firewalls and Mobile IP
  5525.   entities", S. Glass, V. Gupta, 03/27/1997, 
  5526.   <draft-ietf-mobileip-firewall-trav-00.txt>                               
  5527.  
  5528.     The use of network security mechanisms such as ingress filtering, 
  5529.     firewall systems and private address spaces can disrupt normal 
  5530.     operation of Mobile IP [GuGl97]. This document outlines behavioral 
  5531.     guidelines for Mobile Nodes, their Home Agents and intervening 
  5532.     Firewalls.  Compliance with these guidelines allows secure datagram 
  5533.     exchange between a mobile node and its home agent even across 
  5534.     firewalls, ingress filtering routers and distinct address spaces. To 
  5535.     its correspondent nodes, the mobile node appears to be connected to its
  5536.     home network even while roaming on the general Internet. It enjoys the 
  5537.     same connectivity (modulo performance penalities) and, if desired, 
  5538.     privacy outside its protected domain as on the inside.   The guidelines
  5539.     described here solve a restricted, but still useful, variant of the 
  5540.     general firewall traversal problem for Mobile IP. They make the 
  5541.     following assumptions: (a) All intervening firewalls belong to the 
  5542.     mobile node's protected home domain and their existence and relative 
  5543.     placement, with respect to a mobile node's current location, is known a
  5544.     priori. (b) Mobile nodes use co-located care-of addresses (rather than 
  5545.     Foreign Agents) when outside their protected home domain. (c) Firewalls
  5546.     implement standard                                                     
  5547.  
  5548. Multiprotocol Label Switching (mpls)
  5549. ------------------------------------
  5550.  
  5551.   "A Framework for Multiprotocol Label Switching", Ross Callon, George 
  5552.   Swallow, N. Feldman, A. Viswanathan, P. Doolan, A. Fredette, 08/02/1997, 
  5553.   <draft-ietf-mpls-framework-01.txt>                                       
  5554.  
  5555.     This document discusses technical issues and requirements for the
  5556.        Multiprotocol Label Switching working group. This is an initial 
  5557.     draft
  5558.        document, which will evolve and expand over time. It is the intent 
  5559.     of
  5560.        this document to produce a coherent description of all significant
  5561.        approaches which were and are being considered by the working group.
  5562.        Selection of specific approaches, making choices regarding
  5563.        engineering tradeoffs, and detailed protocol specification, are
  5564.        outside of the scope of this framework document.
  5565.      
  5566.        Note that this document is at an early stage, and that most of the
  5567.        detailed technical discussion is only in a rough form. Additional
  5568.        text will be provided over time from a number of sources.  A small
  5569.        amount of the text in this document may be redundant with the
  5570.        proposed protocol architecture for MPLS. This redundancy will be
  5571.        reduced over time, with the overall discussion of issues moved to be
  5572.        in this document, and the selection of specific approaches and
  5573.        specification of the protocol contained in the protocol architecture
  5574.        and other related documents.                                        
  5575.  
  5576.   "A Proposed Architecture for MPLS", Ross Callon, A. Viswanathan, E. 
  5577.   Rosen, 08/21/1997, <draft-ietf-mpls-arch-00.txt>                         
  5578.  
  5579.     This internet draft contains a draft protocol architecture for
  5580.        multiprotocol label switching (MPLS). The proposed architecture is
  5581.        based on other label switching approaches [2-11] as well as on the
  5582.        MPLS Framework document [1].                                        
  5583.  
  5584. Next Generation Transition (ngtrans)
  5585. ------------------------------------
  5586.  
  5587.   "A proposal for an IPv6 site database object", G. de Groot, David 
  5588.   Kessens, 06/06/1997, <draft-ietf-ngtrans-6bone-registry-01.txt>          
  5589.  
  5590.     This proposal describes the proposed syntax of a new RIPE database 
  5591.     object that describes the several IPv6 sites in the world. The object 
  5592.     and resulting database collection will be used to facilitate the 
  5593.     introduction of IPv6 in the Internet.                                  
  5594.  
  5595.   "Site prefixes in Neighbor Discovery", Erik Nordmark, 07/30/1997, 
  5596.   <draft-ietf-ngtrans-header-trans-00.txt>                                 
  5597.  
  5598.     This document specifies a transition mechanism in addition to those
  5599.        already specified in RFC 1933.  The new mechanism can be used as 
  5600.     part
  5601.        of a solution that allows IPv6 hosts that do not have a permanently
  5602.        assigned IPv4 address to communication with IPv4-only hosts.        
  5603.  
  5604. NNTP Extensions (nntpext)
  5605. -------------------------
  5606.  
  5607.   "Network News Transport Protocol", Stan Barber, 09/10/1997, 
  5608.   <draft-ietf-nntpext-base-02.txt>                                         
  5609.  
  5610.                 The Network News Transport Protocol has been in use in the
  5611.                 Internet for a decade and remains one of the most popular
  5612.                 protocols (by volume) in use today. This document is a
  5613.                 replacement for RFC 977 and officially updates the protocol
  5614.                 specification. It clarifies some vagueness in RFC 977,
  5615.                 includes some new base functionality and provides a 
  5616.     specific
  5617.                 mechanism to add standardized extensions to NNTP.          
  5618.  
  5619.   "Common NNTP Extensions",, 10/13/1997, <draft-ietf-nntpext-imp-00.txt>   
  5620.  
  5621.         In this document, a number of popular extensions to the NNTP
  5622.         protocol defined in RFC977 are documented and discussed. While
  5623.         this document is not intended to serve as a standard of any kind,
  5624.         it will hopefully serve as a reference document for future
  5625.         implementers of the NNTP protocol. In the role, this document
  5626.         would hopefully create the possibility for some level of
  5627.         interoperability among implementations that make use of extensions.
  5628.  
  5629. Individual Submissions (none)
  5630. -----------------------------
  5631.  
  5632.   "Definitions of Managed Objects for the Fabric Element in Fibre Channel 
  5633.   Standard", K. Teow, 10/15/1997, <draft-teow-fabric-mib-03.txt>           
  5634.  
  5635.     This memo defines an experimental portion of the Management Information
  5636.     Base (MIB) for use with network management protocols in the Internet
  5637.     community.  In particular, it defines the objects for managing the
  5638.     operations of the Fabric Element portion of the Fibre Channel Methods.
  5639.     
  5640.     This memo specifies a MIB module in a manner that is both compliant to
  5641.     the SNMPv2 SMI, and semantically identical to the peer SNMPv1
  5642.     definitions.                                                           
  5643.  
  5644.   "Procedures for Formalizing, Evolving, and Maintaining the Internet X.500
  5645.   Directory Schema", R. Wright, Tim Howes, K. Rossen, Sri Sataluri, 
  5646.   06/08/1995, <draft-howes-x500-schema-03.txt>                             
  5647.  
  5648.     The IETF Schema Task Force proposes a set of procedures for reviewing, 
  5649.     publicizing, and maintaining schema elements for use in Internet 
  5650.     applications using OSI Directory Services (X.500).                     
  5651.  
  5652.   "Mobility Support in IPv6", C. Perkins, F. Teraoka, D. Johnson, 
  5653.   06/03/1997, <draft-teraoka-ipv6-mobility-sup-04.txt>                     
  5654.  
  5655.     This memo describes a protocol to support mobility in IPv6.  The mobile
  5656.     node has an identifier (home address) and a temporary address (care-of 
  5657.     address).  The IPv6 base header includes the temporary addresses so 
  5658.     that the source and destination addresses are always topologically 
  5659.     significant, while the identifiers are included in the Destination 
  5660.     Options Header.  End nodes may have authentic cache information between
  5661.     identifiers and addresses for routing optimization.  This protocol 
  5662.     introduces two new destination options: `Source Identifier' and 
  5663.     `Destination Identifier', and also introduces two control packets using
  5664.     UDP.                                                                   
  5665.  
  5666.   "Photuris: Session Key Management Protocol", P. Karn, W. Simpson, 
  5667.   09/03/1997, <draft-simpson-photuris-16.txt>                              
  5668.  
  5669.     Photuris is a session-key management protocol intended for use with the
  5670.     IP Security Protocols (AH and ESP).  This document defines the basic 
  5671.     protocol mechanisms.                                                   
  5672.  
  5673.   "The Auto-Submitted, Supersedes and Expires E-mail Headers", J. Palme, 
  5674.   09/10/1997, <draft-ietf-mailext-new-fields-10.txt>                       
  5675.  
  5676.     This memo introduces three new e-mail headers, Auto-Submitted,
  5677.     Supersedes, and Expires.                                               
  5678.  
  5679.   "Distance-Vector Multicast Routing Protocol MIB", D. Thaler, 04/30/1997, 
  5680.   <draft-thaler-dvmrp-mib-04.txt>                                          
  5681.  
  5682.     This memo defines an experimental portion of the Management Information
  5683.     Base (MIB) for use with network management protocols in the Internet 
  5684.     community.  In particular, it describes managed objects used for 
  5685.     managing the Distance-Vector Multicast Routing Protocol (DVMRP) 
  5686.     protocol [5,6].  This MIB module is applicable to IP multicast routers 
  5687.     which implement DVMRP.                                                 
  5688.  
  5689.   "Loop control for the Auto-Submitted e-mail header", J. Palme, 
  5690.   07/07/1997, <draft-palme-autosub-03.txt>                                 
  5691.  
  5692.     This memo introduces certain advanced features for the Auto-Submitted 
  5693.     e-mail header.                                                         
  5694.  
  5695.   "SMTP Service Extension for Authentication", J Myers, 10/28/1997, 
  5696.   <draft-myers-smtp-auth-08.txt>                                           
  5697.  
  5698.        This document defines an SMTP service extension [ESMTP] whereby an
  5699.        SMTP client may indicate an authentication mechanism to the server,
  5700.        perform an authentication protocol exchange, and optionally 
  5701.     negotiate
  5702.        a security layer for subsequent protocol interactions.  This
  5703.        extension is a profile of the Simple Authentication and Security
  5704.        Layer [SASL].                                                       
  5705.  
  5706.   "Tunneling SSL Through a WWW Proxy", A. Luotonen, 03/26/1997, 
  5707.   <draft-luotonen-ssl-tunneling-03.txt>                                    
  5708.  
  5709.     The wide success of SSL (Secure Sockets Layer from Netscape 
  5710.     Communications Corporation) has made it vital that the current WWW 
  5711.     proxy protocol be extended to allow an SSL client to open a secure 
  5712.     tunnel through the proxy.                                              
  5713.  
  5714.   "Common NNTP Extensions", Stan Barber, 04/14/1997, 
  5715.   <draft-barber-nntp-imp-07.txt>                                           
  5716.  
  5717.     In this document, a number of popular extensions to the NNTP protocol 
  5718.     defined in RFC977 are documented and discussed. While this document is 
  5719.     not intended to serve as a standard of any kind, it will hopefully 
  5720.     serve as a reference document for future implementers of the NNTP 
  5721.     protocol. In the role, this document would hopefully create the 
  5722.     possibility for some level of interoperability among implementations 
  5723.     that make use of extensions.                                           
  5724.  
  5725.   "Guidelines for IETF Meeting Sites", E. Love, Dave Crocker, Bill Manning,
  5726.   Mark Prior, S. Coppins, 10/06/1997, 
  5727.   <draft-prior-future-host-guidelines-02.txt>                              
  5728.  
  5729.         The IETF is an international group that conducts most of its
  5730.         business using electronic mail however three times a year it
  5731.         conducts an open meeting for one week. For the most part the actual
  5732.         mechanics of the meeting are organised by the IETF secretariat but
  5733.         there are some requirements placed on the local host.
  5734.      
  5735.         This document attempts to provide some guidelines for organisations
  5736.         that wish to volunteer to act as host for one of these open
  5737.         meetings. As the IETF growth pattern mirrors the Internet itself
  5738.         this document expresses sizes as a percentage of the expected
  5739.         attendance rather than use fixed numbers as we expect these numbers
  5740.         to change for each meeting. At the last meeting, in Munich Germany,
  5741.         there were just over 1300 attendees.
  5742.                                                                            
  5743.  
  5744.   "The META Tag of HTML", D. Musella, 03/24/1997, 
  5745.   <draft-musella-html-metatag-03.txt>                                      
  5746.  
  5747.     This document defines a strict synopsis to catalogue an HTML document 
  5748.     using the META tag of HTML.  The given definition wants to define a 
  5749.     base subset of cataloguing keys to provide a preliminary classification
  5750.     method.                                                                
  5751.  
  5752.   "ICMP Security Failures Messages", P. Karn, W. Simpson, 04/30/1996, 
  5753.   <draft-simpson-icmp-ipsec-fail-02.txt>                                   
  5754.  
  5755.     This document specifies ICMP messages for indicating failures when 
  5756.     using IP Security Protocols (AH and ESP).                              
  5757.  
  5758.   "PEM Compression Encryption Module", H. Woodward, 05/05/1997, 
  5759.   <draft-woodward-encryption-module-00.txt>                                
  5760.  
  5761.     The Privacy-Enhanced Electronic Mail system (PEM) [1] provides an 
  5762.     inclusive standard as adopted by the Internet Architecture Board (IAB) 
  5763.     to provide secure electronic mail over the Internet.  The PEM protocols
  5764.     [2] provide for encryption, authentication, message integrity, and key 
  5765.     management.  PEM's encryption [3] accomplishes privacy of messages 
  5766.     using DES in CBC mode; Integrity [4] via a cryptographic hash algorithm
  5767.     called a Message Integrity Check (MIC)using either MD2 or MD5; 
  5768.     Symmetric key management [5] using DES in ECB mode or triple-DES using 
  5769.     two keys (EDE mode); and supports [6] public-key certificates for key 
  5770.     management, using the RSA algorithm and X.509 standard for certificate 
  5771.     structure.    This document describes the use of a Spiral Network 
  5772.     Algorithm Compression routine integrated into the message-text 
  5773.     encryption routines to provide enhanced confidentiality and smaller 
  5774.     message size without impacting the throughput of the PEM system.  It is
  5775.     the intention of the author to seek guidance from the readers on 
  5776.     methods of testing and certification other than those listed herein.   
  5777.  
  5778.   "Layer Two Forwarding (Protocol) 'L2F'", T. Kolar, M. Littlewood, A. 
  5779.   Valencia, 10/07/1997, <draft-valencia-l2f-00.txt>                        
  5780.  
  5781.        Virtual dial-up allows many separate and autonomous protocol domains
  5782.        to share common access infrastructure including modems, Access
  5783.        Servers, and ISDN routers.  Previous RFCs have specified protocols
  5784.        for supporting IP dial-up via SLIP [1] and multiprotocol dial-up via
  5785.        PPP [2].  This document describes the Layer Two Forwarding protocol
  5786.        (L2F) which permits the tunneling of the link layer (i.e., HDLC,
  5787.        async HDLC, or SLIP frames) of higher level protocols.  Using such
  5788.        tunnels, it is possible to divorce the location of the initial dial-
  5789.        up server from the location at which the dial-up protocol connection
  5790.        is terminated and access to the network provided.                   
  5791.  
  5792.   "The "data" URL scheme", Larry Masinter, 03/19/1997, 
  5793.   <draft-masinter-url-data-03.txt>                                         
  5794.  
  5795.     A new URL scheme, 'data', is defined. It allows inclusion of small data
  5796.     items as 'immediate' data, as if it had been included externally.      
  5797.  
  5798.   "Header Compression for IPv6", S. Pink, M. Degermark, B. Nordgren, 
  5799.   08/04/1997, <draft-degermark-ipv6-hc-03.txt>                             
  5800.  
  5801.     This document describes how to compress IP headers per-hop over
  5802.        point-to-point links.  The methods can be applied to IPv6 base and
  5803.        extension headers, IPv4 headers, TCP and UDP headers, and
  5804.        encapsulated IPv6 and IPv4 headers.
  5805.     
  5806.        Headers of typical UDP or TCP packets can be compressed down to 4-7
  5807.        octets including the 2 byte UDP or TCP checksum.  This largely
  5808.        removes the negative impact of large headers and allows efficient 
  5809.     use
  5810.        of bandwidth on low- and medium-speed links.                        
  5811.  
  5812.   "Mail Ubiquitous Security Extensions (MUSE)", Don Eastlake, 05/12/1997, 
  5813.   <draft-eastlake-muse-02.txt>                                             
  5814.  
  5815.     Secure electronic mail can provide authentication of the source of mail
  5816.     and confidentiality for its contents.  These features are becoming 
  5817.     increasingly important as the Internet grows exponentially and email is
  5818.     increasingly used for critical, sensitive, and confidential 
  5819.     communications.  In addition, authentication can make mail filtering 
  5820.     more effective and ubiquitous encryption indirectly makes all mail more
  5821.     secure be defeating traffic analysis based on distinctions between 
  5822.     encrypted and non-encrypted mail and defeating bulk searching through 
  5823.     insecure mail. However, use of secure mail is not widespread due to the
  5824.     problems of key distribution and lack of migration to secure mail 
  5825.     enabled user agents.  This draft proposes partial solutions to these 
  5826.     two problems by using coarser grained identity to permit some 
  5827.     authentication and confidentiality without user agent change, and 
  5828.     secure DNS for key distribution.  These changes also support limited 
  5829.     host and domain level mail security policies.                          
  5830.  
  5831.   "The Hash Convention For Mail System Status Codes (HCMSSC)", D. 
  5832.   Bernstein, 02/03/1997, <draft-bernstein-hcmssc-02.txt>                   
  5833.  
  5834.     RFC 1893 defines codes for mail delivery failures. For example, code 
  5835.     5.1.1 means that the specified mailbox does not exist.                 
  5836.     The qmail package sprays these codes all over the place, by adding a 
  5837.     code to the text of every error message, preceded by a hash mark and 
  5838.     surrounded by parentheses. It avoids using hash marks elsewhere.       
  5839.  
  5840.   "The qmail-send Bounce Message Format (QSBMF)", D. Bernstein, 02/03/1997,
  5841.   <draft-bernstein-qsbmf-02.txt>                                           
  5842.  
  5843.     When a message transport agent (MTA) finds itself permanently unable to
  5844.     deliver a mail message, it generates a new message, generally known as 
  5845.     a bounce message, back to the envelope sender.                         
  5846.     Bounce messages produced by the qmail-send program display the list of 
  5847.     failed recipient addresses, an explanation for each address, and a copy
  5848.     of the original message, in a format that is easy for both humans and 
  5849.     programs to read. This document defines the format.                    
  5850.  
  5851.   "Easily Parsed LIST Format (EPLF)", D. Bernstein, 02/03/1997, 
  5852.   <draft-bernstein-eplf-02.txt>                                            
  5853.  
  5854.     The File Transfer Protocol (FTP) supports two commands that list files:
  5855.     NLST and LIST. The NLST response is easy to parse but provides very 
  5856.     little information. The LIST response provides more information, but in
  5857.     a format that varies from system to system. The most common LIST 
  5858.     formats are undocumented and impossible to parse reliably.             
  5859.     This document defines Easily Parsed LIST Format (EPLF), a format for 
  5860.     the LIST response that is usable by humans yet easy for programs to 
  5861.     handle. This format is supported by anonftpd, a secure FTP server.     
  5862.     One visible advantage of EPLF is that a browser can easily display 
  5863.     dates in the viewer's time zone and native language. EPLF also makes it
  5864.     straightforward for an indexing program to automatically traverse an 
  5865.     FTP area and for a mirroring program to avoid downloading the same file
  5866.     twice.                                                                 
  5867.  
  5868.   "Netstrings", D. Bernstein, 02/03/1997, 
  5869.   <draft-bernstein-netstrings-02.txt>                                      
  5870.  
  5871.     A netstring is a self-delimiting encoding of a string. Netstrings are 
  5872.     very easy to generate and to parse. Any string may be encoded as a 
  5873.     netstring; there are no restrictions on length or on allowed bytes. 
  5874.     Another virtue of a netstring is that it declares the string size up 
  5875.     front. Thus an application can check in advance whether it has enough 
  5876.     space to store the entire string.                                      
  5877.     Netstrings may be used as a basic building block for reliable network 
  5878.     protocols. Most high-level protocols, in effect, transmit a sequence of
  5879.     strings; those strings may be encoded as netstrings and then 
  5880.     concatenated into a sequence of characters, which in turn may be 
  5881.     transmitted over a reliable stream protocol such as TCP.               
  5882.  
  5883.   "Tools in the War on Mail Loops", D. Bernstein, 02/03/1997, 
  5884.   <draft-bernstein-mail-loops-war-02.txt>                                  
  5885.  
  5886.     An automailer means any program that receives a mail message and 
  5887.     automatically sends one or more mail messages. This term is meant to 
  5888.     include not only a mail-based server, such as a mailing list exploder 
  5889.     or a vacation program, but also an SMTP server, which receives a 
  5890.     message from the network and relays it to a local or remote user.      
  5891.     In a network full of automailers, any mistake can cause a mail loop.  
  5892.     Since some automailers generate several outputs in response to a single
  5893.     input, a loop can produce an exponential explosion of mail.            
  5894.     All the automailers in the qmail package follow a general philosophy 
  5895.     designed to prevent mail loops and limit the damage from any loops that
  5896.     do occur. These automailers have been repeatedly observed to fail safe:
  5897.     they stop loops in the face of typical failures by other hosts. This 
  5898.     document explains the philosophy and describes the automailers.        
  5899.  
  5900.   "Public Information Retrieval Protocol (PIRP)", D. Bernstein, 02/03/1997,
  5901.   <draft-bernstein-pirp-02.txt>                                            
  5902.  
  5903.     The Public Information Retrieval Protocol (PIRP) gives Internet hosts a
  5904.     simple, uniform, efficient, extensible, easily implemented method of 
  5905.     publishing information. This document defines PIRP and outlines the 
  5906.     structure of PIRP names.                                               
  5907.     Unlike FTP and HTTP, PIRP is dedicated to publication. Implementing 
  5908.     PIRP ought to be a small and trivial task.                             
  5909.  
  5910.   "Notice-Requested-Upon-Delivery-To (NRUDT)", D. Bernstein, 02/03/1997, 
  5911.   <draft-bernstein-nrudt-02.txt>                                           
  5912.  
  5913.     The UNIX sendmail program has for many years supported a 
  5914.     Return-Receipt-To (RRT) header field that requests a notice of 
  5915.     successful final delivery.    Notice-Requested-Upon-Delivery-To (NRUDT)
  5916.     has the same basic function. The big difference is that RRT lists the 
  5917.     sender's address, while NRUDT lists the recipient's address.           
  5918.     This change is critical. RRT works poorly for messages to multiple 
  5919.     recipients, because it requests a notice from every recipient. RRT in a
  5920.     message to a large mailing list produces a giant, usually 
  5921.     unintentional, flood of mail. This problem is so severe that RRT has 
  5922.     been disabled in recent versions of sendmail.                          
  5923.     NRUDT is designed to be adopted immediately, with minimal disruption, 
  5924.     as a solution to the problems of RRT. Note that NRUDT is merely a 
  5925.     request for notification; unlike the link-level Delivery Status 
  5926.     Notification SMTP extension, NRUDT does not provide a guarantee of 
  5927.     notification.                                                          
  5928.  
  5929.   "Photuris: Extended Schemes and Attributes", P. Karn, W. Simpson, 
  5930.   07/24/1997, <draft-simpson-photuris-schemes-03.txt>                      
  5931.  
  5932.     Photuris is a session-key management protocol.  Extensible 
  5933.     Exchange-Schemes are provided to enable future implementation changes 
  5934.     without affecting the basic protocol.                                  
  5935.     Additional authentication attributes are included for use with the IP 
  5936.     Authentication Header (AH).                                            
  5937.     Additional confidentiality attributes are included for use with the IP 
  5938.     Encapsulating Security Protocol (ESP).                                 
  5939.  
  5940.   "Internet Security Transform Enhancements", W. Simpson, D. Wagner, 
  5941.   04/30/1997, <draft-simpson-ipsec-enhancement-01.txt>                     
  5942.  
  5943.     This document describes several generic security transform enhancements
  5944.     for the IP Security Protocols (AH and ESP).                            
  5945.  
  5946.   "IANA Charset Registration Procedures", J. Postel, Ned Freed, 09/30/1997,
  5947.   <draft-freed-charset-reg-04.txt>                                         
  5948.  
  5949.     MIME [RFC-2045, RFC-2046, RFC-2047, RFC-2184] and various
  5950.     other modern Internet protocols are capable of using many
  5951.     different charsets. This in turn means that the ability to
  5952.     label different charsets is essential. This registration
  5953.     procedure exists solely to associate a specific name or names
  5954.     with a given charset and to give an indication of whether or
  5955.     not a given charset can be used in MIME text objects. In
  5956.     particular, the general applicability and appropriateness of a
  5957.     given registered charset is a protocol issue, not a
  5958.     registration issue, and is not dealt with by this registration
  5959.     procedure.                                                             
  5960.  
  5961.   "TFTP Blocksize Option", G. Malkin, Art Harkin, 07/24/1997, 
  5962.   <draft-malkin-tftpexts-blksize-opt-01.txt>                               
  5963.  
  5964.     The Trivial File Transfer Protocol [1] is a simple, lock-step, file 
  5965.     transfer protocol which allows a client to get or put a file onto a 
  5966.     remote host.  One of its primary uses is the booting of diskless nodes 
  5967.     on a Local Area Network.  TFTP is used because it is very simple to 
  5968.     implement in a small node's limited ROM space.  However, the choice of 
  5969.     a 512-octet blocksize is not the most efficient for use on a LAN whose 
  5970.     MTU may 1500 octets or greater.                                        
  5971.     This document describes a TFTP option which allows the client and 
  5972.     server to negotiate a blocksize more applicable to the network medium. 
  5973.     The TFTP Option Extension mechanism is described in [2].               
  5974.  
  5975.   "IP Authentication using Keyed SHA1 with Data Padding", W. Simpson, Perry
  5976.   Metzger, 05/01/1996, <draft-simpson-ah-sha-kdp-00.txt>                   
  5977.  
  5978.     This document describes the use of keyed SHA1 with the IP 
  5979.     Authentication Header.                                                 
  5980.  
  5981.   "A Clarification of the STATUS Clause in SNMP MIB Modules", David 
  5982.   Perkins, 06/12/1997, <draft-rfced-info-perkins-02.txt>                   
  5983.  
  5984.     This memo is informational.  It specifies a clarification of the 
  5985.     meaning and use of the STATUS clause in Simple Network Management 
  5986.     Protocol (SNMP) Management Information Base (MIB) modules, which are 
  5987.     defined by the Structure of Management Information (SMI).  There are 
  5988.     two versions of the SMI.  The first, called SMIv1, is defined by RFCs 
  5989.     1155[1],  1212[2], and 1215[3].  The second, called SMIv2, is defined 
  5990.     by RFCs 1902[4], 1903[5], and 1904[6].  Many of the MIB module 
  5991.     constructs defined by the SMIs such as OBJECT-IDENTITY, OBJECT-TYPE, 
  5992.     and NOTIFICATION-TYPE contain the STATUS clause.  However, the SMIs do 
  5993.     not provide a complete definition of the STATUS clause, nor do they 
  5994.     provide guidance to MIB designers and users on the interpretation and 
  5995.     action required dependent upon the value or change of value for a 
  5996.     STATUS clause.  Users include agent and application developers, and 
  5997.     operators of SNMP-managed networks.                        This memo 
  5998.     specifies a clarification for both version 1 and version 2 of the SNMP 
  5999.     SMI, which is a standard for the Internet community.                   
  6000.  
  6001.   "Using the MARS model in non-ATM NBMA networks.", G. Armitage, 
  6002.   07/10/1997, <draft-armitage-ion-mars-nbma-02.txt>                        
  6003.  
  6004.     Initially developed for IP over ATM, the RFC2022 (MARS) model is also 
  6005.     applicable to other NBMA networks that provide the equivalent of 
  6006.     switched, point to multipoint connections. This short document is 
  6007.     intended to state the obvious equivalences, and explain the less 
  6008.     obvious implications. No changes to the MARS model per se are suggested
  6009.     or required. RFC2022 is not required over NBMA networks that offer 
  6010.     Ethernet-like group addressing functionality.                          
  6011.  
  6012.   "The Domestication of the Opaque Type for SNMP", David Perkins, 
  6013.   06/12/1997, <draft-perkins-opaque-01.txt>                                
  6014.  
  6015.     This memo is informational.  It specifies a clarification of the 
  6016.     definition and use of the Opaque type defined in Simple Network 
  6017.     Management Protocol (SNMP) Structure of Management Information (SMI).  
  6018.  
  6019.   "Multiple MCS support using an enhanced version of the MARS server.", M. 
  6020.   Ammar, R. Talpade, 12/26/1996, <draft-talpade-ion-multiplemcs-01.txt>    
  6021.  
  6022.     The basic Multicast Server architecture for layer 3 multicast over ATM 
  6023.     has been described in draft-ietf-ion-marsmcs-01.txt.  It includes a 
  6024.     mechanism for fault tolerance using multiple MCSs.  However no support 
  6025.     for sharing senders/receivers of a group across multiple MCSs has been 
  6026.     provided.  This document aims to satisfy this need by involving an 
  6027.     enhanced version of the MARS in the load sharing and fault tolerance 
  6028.     mechanism.  This approach is an improvement over the previous one as it
  6029.     subverts the need for any inter-MCS synchronization mechanisms.        
  6030.  
  6031.   "Message Submission and Relay", Harald Alvestrand, R. Gellens, 
  6032.   05/08/1997, <draft-gellens-submit-05.txt>                                
  6033.  
  6034.     SMTP was defined as a message *relay* protocol, that is, a means for 
  6035.     message transfer agents (MTAs) to route finished (complete) messages.  
  6036.     SMTP forbids MTAs from altering the message text, except to add 
  6037.     'Received' header fields.    However, SMTP is now also widely used as a
  6038.     message *submission* protocol, that is, a means for message user agents
  6039.     (MUAs) to introduce new messages into the MTA routing network.  
  6040.     Regardless of whether this is good or bad, it is far too late to 
  6041.     change.                                                                
  6042.  
  6043.   "The Public Key Login Protocol", D. Kemp, 08/01/1997, 
  6044.   <draft-kemp-auth-pklogin-03.txt>                                         
  6045.  
  6046.     This document defines the Public Key Login (PKL) protocol, a challenge-
  6047.     response authentication mechanism using digital signatures. It provides
  6048.     start-of-session authentication for firewall proxies, dial-up Network
  6049.     Access Servers, remote email servers, and interactive protocols such as
  6050.     Telnet and FTP. It provides functionality similar to One Time Passwords
  6051.     and handheld authentication tokens, and it supports both one-way and
  6052.     mutual authentication. PKL uses the authentication exchanges specified
  6053.     in ISO/IEC 9798-3 and NIST FIPS Pub 196.
  6054.      
  6055.     The PKL protocol provides strong authentication at the beginning of a
  6056.     session, but does not by itself provide communication channel integrity
  6057.     or confidentiality. PKL should be used in conjunction with a channel
  6058.     integrity mechanism, for example to provide authentication of 
  6059.     individual
  6060.     users over (host-keyed) Virtual Private Network connections.
  6061.      
  6062.     This Internet Draft is intended to be the last version of the PKL
  6063.     specification prior to publication as an Informational RFC. Comments 
  6064.     are
  6065.     requested no later than the expiration date of this draft.             
  6066.  
  6067.   "Voice Profile for Internet Mail - version 2", G. Vaudreuil, G. Parsons, 
  6068.   04/18/1997, <draft-ema-vpim-05.txt>                                      
  6069.  
  6070.     A class of special-purpose computers has evolved to provide voice 
  6071.     messaging services.  These machines generally interface to a telephone 
  6072.     switch and provide call answering and voice messaging services.  
  6073.     Traditionally, messages sent to a non-local machine are transported 
  6074.     using analog networking protocols based on DTMF signaling and analog 
  6075.     voice playback.  As the demand for networking increases, there is a 
  6076.     need for a standard high-quality digital protocol to connect these 
  6077.     machines.  The following document is a profile of the Internet standard
  6078.     MIME and ESMTP protocols for use as a digital voice messaging 
  6079.     networking protocol. The profile is referred to as VPIM (Voice Profile 
  6080.     for Internet Mail) in this document.    This profile is based on 
  6081.     earlier work in the Audio Message Interchange Specification (AMIS) 
  6082.     group that defined a voice messaging protocol based on X.400 
  6083.     technology.  This profile is intended to satisfy the user requirements 
  6084.     statement from that earlier work with the industry standard ESMTP/MIME 
  6085.     mail protocol infrastructures already used within corporate intranets. 
  6086.     This second version of VPIM is based on implementation experience and 
  6087.     obsoletes RFC 1911 which describes                                     
  6088.  
  6089.   "A Common Internet File System (CIFS/1.0) Protocol                  
  6090.   Preliminary Draft", P. Leach, D. Naik, 03/26/1997, 
  6091.   <draft-leach-cifs-v1-spec-00.txt>                                        
  6092.  
  6093.     This document describes the CIFS file sharing protocol, version 1.0. 
  6094.     Client systems use this protocol to request file and  print services 
  6095.     from server systems over a network. It is based on the Server Message 
  6096.     Block protocol widely in use by personal computers and workstations 
  6097.     running a wide variety of operating systems.                           
  6098.  
  6099.   "Redundant MARS architectures and SCSP", G. Armitage, 07/03/1997, 
  6100.   <draft-armitage-ion-mars-scsp-03.txt>                                    
  6101.  
  6102.     The Server Cache Synchronisation Protocol (SCSP) has been proposed as a
  6103.     general mechanism for synchronising the contents of databases. This 
  6104.     document identifies a range of distributed MARS (RFC 2022) scenarios, 
  6105.     highlights associated problems, and describe the issues the must be 
  6106.     addressed when using SCSP to synchronize a distributed MARS.           
  6107.  
  6108.   "Quality of Service Extensions to OSPF or Quality Of Service Path First 
  6109.   Routing (QOSPF)", W. Salkewicz, Eric Crawley, Z. Zhang, C. Sanchez, 
  6110.   09/10/1997, <draft-zhang-qos-ospf-01.txt,.ps>                            
  6111.  
  6112.     This document describes a series of extensions for OSPF[1] and MOSPF[2]
  6113.     that can be used to provide Quality of Service (QoS) routing in
  6114.     conjunction with a resource reservation protocol such as RSVP[4] or
  6115.     other mechanisms that can notify routing of the QoS needs of a data
  6116.     flow. Advertisements indicating the resources available and the
  6117.     resources used are advertised to the OSPF routing domain and paths are
  6118.     computed based on topology information, link resource information, and
  6119.     the resource requirements of a particular data flow.                   
  6120.  
  6121.   "Making Postscript and Acrobat Files International", J. Palme, 
  6122.   08/21/1997, <draft-palme-int-print-02.txt>                               
  6123.  
  6124.     Certain text formats, for example Postscript (extension .ps, Mime-type
  6125.     application/postscript) and Adobe Acrobat (extension .pdf, Mime-type
  6126.     application/pdf) specify exactly the page layout of the printed
  6127.     document. The commonly used paper format is different in America and 
  6128.     the
  6129.     rest of the world. America uses the                                    
  6130.  
  6131.   "Compression Payload for Use with IP Security", Rodney Thayer, 
  6132.   03/24/1997, <draft-thayer-seccomp-01.txt>                                
  6133.  
  6134.     This document describes a payload format to be used to store compressed
  6135.     protocol messages within an IP packet which is using security features 
  6136.     as defined in [RFC-1825].                                              
  6137.  
  6138.   "Requirements for IETF Mailing Lists", Keith Moore, 09/26/1997, 
  6139.   <draft-moore-maillist-req-01.txt>                                        
  6140.  
  6141.     This document describes requirements for all IETF official mailing
  6142.     lists, including (but not limited to) mailing lists used for working
  6143.     group discussion.                                                      
  6144.  
  6145.   "Internet Discussion Forum Protocol (IDFP)", L. Martins, 01/03/1997, 
  6146.   <draft-martins-forums-01.txt>                                            
  6147.  
  6148.     This document presents a new alternative way of implementing discussion
  6149.     forums other than NNTP and mailing lists. It is largely based on 
  6150.     standard e-mail except for retrieval. The purpose of this new protocol 
  6151.     is to atenuate the bandwidth and net resources needed by either NNTP 
  6152.     and mailing lists.                                                     
  6153.     Based on implementation experience by me and Kovisoft, the remote 
  6154.     moderator capabilities have been rewriten (in fact this was because I 
  6155.     conceived a better way).                                               
  6156.  
  6157.   "Dedicated Token Ring Interface MIB", K. Lee, T. Warwick, 03/05/1997, 
  6158.   <draft-warwick-tokenring-01.txt>                                         
  6159.  
  6160.     This document contains an extract from Draft 7 of the IEEE standard 
  6161.     802.5R 'Dedicated Token Ring'.   The extract comprises the Interface 
  6162.     MIB for the Dedicated Token Ring interface, in SNMPv2 format.  Draft 7 
  6163.     is now undergoing an IEEE sponsor ballot that is expected to complete 
  6164.     in April 1997, and has also been submitted for ballot to ISO. No major 
  6165.     changes to the MIB are expected as a result of these ballots.          
  6166.     802.5R is a standard that encompasses the existing 802.5 token-passing 
  6167.     method of operation, and also defines a new duplex method of operation 
  6168.     for use only on dedicated point to point links, that does not use 
  6169.     tokens for data transmission.                                          
  6170.  
  6171.   "Dedicated Token Ring Concentrator MIB", K. Lee, T. Warwick, 03/05/1997, 
  6172.   <draft-warwick-tokenring-arch-01.txt>                                    
  6173.  
  6174.     This document contains an extract from Draft 7 of the IEEE standard 
  6175.     802.5R 'Dedicated Token Ring'.   The extract comprises the MIB for the 
  6176.     Dedicated Token Ring Concentrator, in SNMPv2 format.  Draft 7 is now 
  6177.     undergoing an IEEE sponsor ballot that is expected to complete in April
  6178.     1997, and has also been submitted for ballot to ISO. No major changes 
  6179.     to the MIB are expected as a result of these ballots.                  
  6180.     802.5R  is a standard that encompasses the existing 802.5 token-passing
  6181.     method of operation, and also defines a new duplex method of operation 
  6182.     for use only on dedicated point to point links, that does not use 
  6183.     tokens for data transmission.                                          
  6184.     The architecture of a DTR  Concentrator is defined in the 802.5R 
  6185.     standard.  It is a MAC layer bridging device, which uses a new set of 
  6186.     forwarding rules that ease interoperability between source routing and 
  6187.     transparent bridging in an 802.5 LAN.  The DTR Concentrator MIB is 
  6188.     derived from the Source Routing and Transparent Bridge MIBs (RFCs 1525 
  6189.     and 1493).                                                             
  6190.  
  6191.   "The Owner Hack", D. Bernstein, 02/19/1997, 
  6192.   <draft-bernstein-owner-hack-01.txt>                                      
  6193.  
  6194.     The fundamental problem in managing a large mailing list is matching 
  6195.     bounce messages to subscription addresses.                             
  6196.     Often a bounce message refers to a failing address that does not appear
  6197.     on the mailing list. One of the mailing list subscribers is forwarding 
  6198.     messages to that address. Which subscriber? As the list grows, this 
  6199.     question becomes more and more difficult to answer.                    
  6200.     The owner hack completely eliminates this problem _right now_. It 
  6201.     automatically and reliably identifies the subscription address relevant
  6202.     to each bounce message. It provides the address in a form that is 
  6203.     trivial for automated bounce handlers to parse. It requires support 
  6204.     from the local mailer, but it does not require support from any other 
  6205.     hosts.                                                                 
  6206.  
  6207.   "Quick Mail Transfer Protocol (QMTP)", D. Bernstein, 02/03/1997, 
  6208.   <draft-bernstein-qmtp-01.txt>                                            
  6209.  
  6210.     The Quick Mail Transfer Protocol (QMTP) is a replacement for the Simple
  6211.     Mail Transfer Protocol (SMTP). QMTP eliminates any need for end-of-line
  6212.     scanning between hosts with the same end-of-line convention. It 
  6213.     features automatic pipelining and chunking, 8-bit transmission, prior 
  6214.     declaration of the message size, and efficient batching. It is designed
  6215.     to be very easy to implement.                                          
  6216.  
  6217.   "Political Disclosure Transmission Protocol (DISCLOSE)", J. Dixon, 
  6218.   01/16/1997, <draft-rfced-info-dixon-01.txt>                              
  6219.  
  6220.     This document details a protocol which allows political candidates and 
  6221.     related committees to electronically transfer financial disclosure 
  6222.     filings (as now often required by law) to their associated governmental
  6223.     entities, for the purpose of review, and then making these filings 
  6224.     easily publicly accessible.                                            
  6225.  
  6226.   "Creation of and Registration in the ".NUM" Top Level Domain", M. 
  6227.   Schultz, 05/07/1997, <draft-rfced-info-schultz-01.txt>                   
  6228.  
  6229.     This document describes the creation, registration requirements, and 
  6230.     administration of the new top level domain (TLD) NUM.                  
  6231.  
  6232.   "The PORT Resource Record", T. Maginnis, A. Madapoosi, 05/07/1997, 
  6233.   <draft-rfced-exp-maginnis-00.txt>                                        
  6234.  
  6235.     A contributing factor to the explosive growth in IP address allocation 
  6236.     is the coming together of two seeming unrelated factors.  One factor is
  6237.     arbitrary relationship within the Domain Name Server that requires an 
  6238.     unique IP address to be associated with a Domain Name.  The second 
  6239.     factor is the public's desire to have short Domain Names unique to 
  6240.     their enterprise.                                                      
  6241.     We believe a small modification to the Domain Name Server will break 
  6242.     this relationship and lessen pressure on IP address allocation.  This 
  6243.     modification should also make system configuration easier than dealing 
  6244.     with IP addresses for each Domain Name supported on a given host.      
  6245.     One difficulty with the proposed modification is that similar 'small' 
  6246.     changes are required in the WWW browsers to pick up the port number and
  6247.     append it to the URL.                                                  
  6248.  
  6249.   "Ruby in the Hypertext Markup Language", M. Duerst, 03/03/1997, 
  6250.   <draft-duerst-ruby-01.txt>                                               
  6251.  
  6252.     The Hypertext Markup Language (HTML) is a markup language used to 
  6253.     create hypertext documents that are platform independent.  Initially 
  6254.     HTML was designed primarily for Western European languages; most of the
  6255.     issues of basic internationalization to make HTML better usable for 
  6256.     other languages have in the meantime been addressed.  Ruby are 
  6257.     important phonetic annotations used mainly for ideographic characters 
  6258.     in East Asia. This document proposes markup for ruby in HTML and 
  6259.     explains its usage.                                                    
  6260.  
  6261.   "Domain Names and Company Name Retrieval", John Klensin, T. Wolf, 
  6262.   07/28/1997, <draft-klensin-tld-whois-02.txt>                             
  6263.  
  6264.     Location of web information for particular companies based on their 
  6265.     names has become an increasingly difficult problem and the Internet and
  6266.     the web grow.   The use of a naming convention and the domain name 
  6267.     system (DNS) for that purpose has caused complications for the latter 
  6268.     while not solving the problem.  While there have been several proposals
  6269.     to use contemporary, high-capability, directory service and search 
  6270.     protocols to reduce the dependencies on DNS conventions, none of them 
  6271.     have been significantly deployed.                                      
  6272.     This document proposes a company name to URL mapping service based on 
  6273.     the oldest and least complex of Internet directory protocols, whois, in
  6274.     order to explore whether and extremely simple and widely-deployed 
  6275.     protocol can succeed where more complex and powerful options have 
  6276.     failed or been excessively delayed.                                    
  6277.  
  6278.   "Firewall Support for Mobile IP", G. Montenegro, V. Gupta, 08/01/1997, 
  6279.   <draft-montenegro-firewall-sup-01.txt>                                   
  6280.  
  6281.        The Mobile IP specification establishes the mechanisms that enable a
  6282.        mobile host to maintain and use the same IP address as it changes
  6283.        its point of attachment to the network. Mobility implies higher
  6284.        security risks than static operation, because the traffic may at
  6285.        times take unforeseen network paths with unknown or unpredictable
  6286.        security characteristics. The Mobile IP specification makes no
  6287.        provisions for securing data traffic.  The mechanisms described in
  6288.        this document allow a mobile node out on a public sector of the
  6289.        internet to negotiate access past a SKIP firewall, and construct a
  6290.        secure channel into its home network.
  6291.     
  6292.        In addition to securing traffic, our mechanisms allow a mobile node
  6293.        to roam into regions that (1) impose ingress filtering, and (2) use
  6294.        a different address space.
  6295.                                                                            
  6296.  
  6297.   "Tag Distribution Protocol", D Katz, Bruce Davie, Y Rekhter, E. Rosen, P.
  6298.   Doolan, 05/23/1997, <draft-doolan-tdp-spec-01.txt>                       
  6299.  
  6300.     An overview of a  tag switching architecture is provided in [Rekhter]. 
  6301.     This document defines the Tag Distribution Protocol (TDP) referred to 
  6302.     in [Rekhter].                                                          
  6303.     TDP is a two party protocol that runs over a connection oriented 
  6304.     transport layer with guaranteed sequential delivery.  Tag Switching 
  6305.     Routers use TDP to communicate tag binding information to their peers. 
  6306.     TDP supports multiple network layer protocols including but not limited
  6307.     to IPv4, IPv6, IPX and AppleTalk.                                      
  6308.     We define here the PDUs and operational procedures for this TDP and 
  6309.     specify its transport requirements. We also define aspects of the 
  6310.     protocol that are specific to the case where it is run over an ATM 
  6311.     datalink.                                                              
  6312.  
  6313.   "ST2+ over ATM Protocol Specification - UNI 3.1 Version", M. Suzuki, 
  6314.   10/14/1997, <draft-suzuki-st2-over-atm-02.txt>                           
  6315.  
  6316.        This document specifies an ATM-based protocol for communication
  6317.        between ST2+ agents. The ST2+ over ATM protocol supports the 
  6318.     matching
  6319.        of one hop in an ST2+ tree-structure stream with one ATM connection.
  6320.        In this document, ATM is a subnet technology for the ST2+ stream.
  6321.      
  6322.        The ST2+ over ATM protocol is designed to achieve resource-
  6323.        reservation communications across ATM and non-ATM networks, to 
  6324.     extend
  6325.        the UNI 3.1/4.0 signaling functions, and to reduce the UNI 4.0 LIJ
  6326.        signaling limitations.
  6327.      
  6328.        The specifications of the ST2+ over ATM protocol consist of a
  6329.        revision of RFC 1819 ST2+ and specifications of protocol interaction
  6330.        between ST2+ and ATM on the user plane, management plane, and 
  6331.     control
  6332.        plane which correspond to the three planes of the B-ISDN protocol
  6333.        reference model.                                                    
  6334.  
  6335.   "The TACACS+ Protocol Version 1.77", D. Carrel, L. Grant, 07/10/1997, 
  6336.   <draft-grant-tacacs-01.txt>                                              
  6337.  
  6338.     TACACS+ provides access control for routers, network access servers and
  6339.     other networked computing devices via one or more centralized servers. 
  6340.     TACACS+ provides separate authentication, authorization and accounting 
  6341.     services.  This document describes the protocol that is used by 
  6342.     TACACS+.                                                               
  6343.  
  6344.   "EARTH - EAsy IP multicast Routing THrough ATM clouds", M. Smirnov, 
  6345.   03/24/1997, <draft-smirnov-ion-earth-02.txt>                             
  6346.  
  6347.     The EARTH could be positioned between MARS [1] and VENUS [2], however 
  6348.     EARTH deals not only with address resolution but with routing issues as
  6349.     well. This document describes a solution simplifying distribution of IP
  6350.     multicast flows over ATM clouds with the use of point-to-multipoint 
  6351.     connections. The EARTH solution includes:  - the notion of multicast IP
  6352.     subnet over ATM; - IP multicast addresses (Class D) resolution to ATM 
  6353.     addresses; - support for IP multicast shortcuts over multiple LISs and 
  6354.     for the DVMRP capable egress routers; - support for a multicast group 
  6355.     management and receiver-initiated quality of service (QoS) 
  6356.     specification; - optional replication of EARTH servers with server 
  6357.     synchronisation based on SCSP [3].                                     
  6358.     The current version of EARTH proposal has an extension to solve 
  6359.     problems of ATM backbone for the Internet with DVMRP support over MLIS;
  6360.     while retaining  support for ATM subnets (LANs). Another extension 
  6361.     addresses redundant EARTH servers specifying, how SCSP protocol could 
  6362.     be re-designed to run over MLIS.                                       
  6363.  
  6364.   "Network Ingress Filtering: Defeating Denial of Service Attacks which 
  6365.   employ IP Source Address Spoofing", P. Ferguson, D. Senie, 10/09/1997, 
  6366.   <draft-ferguson-ingress-filtering-03.txt>                                
  6367.  
  6368.     Recent occurrences of various Denial of Service (DoS) attacks
  6369.         which have employed forged source addresses have proven to be a
  6370.         troublesome issue for Internet Service Providers and the Internet
  6371.         community overall.  This paper discusses a simple, effective,
  6372.         and straightforward method for using ingress traffic filtering
  6373.         to prohibit DoS attacks which use forged IP addresses to be
  6374.         propagated from 'behind' an Internet Service Provider's (ISP)
  6375.         aggregation point.                                                 
  6376.  
  6377.   "A Method for the Transmission of IPv6 Packets over ARCnet Networks.", I.
  6378.   Souvatzis, 09/02/1997, <draft-souvatzis-ipv6-arcnet-03.txt>              
  6379.  
  6380.     This memo specifies a frame format for transmission of IPv6 [IPV6] 
  6381.     packets and the method of forming IPv6 link-local addresses on ARCnet 
  6382.     networks. It also specifies the content of the Source/Target Link-layer
  6383.     Address option used by the Router Solicitation, Router Advertisement, 
  6384.     Neighbor Solicitation, and Neighbor Advertisement messages described in
  6385.     [DISC], when those messages are transmitted on an ARCnet.              
  6386.  
  6387.   "Use of Tag Switching With ATM", Bruce Davie, George Swallow, 01/17/1997,
  6388.   <draft-davie-tag-switching-atm-01.txt>                                   
  6389.  
  6390.     A tag switching architecture is described in [1].  Tag Switching 
  6391.     enables the use of ATM Switches as Tag Switching Routers. The ATM 
  6392.     Switches run network layer routing algorithms (such as OSPF, IS-IS, 
  6393.     etc.), and their data forwarding is based on the results of these 
  6394.     routing algorithms. No ATM-specific routing or addressing is needed.   
  6395.     This document describes how the tag switching architecture is applied 
  6396.     to ATM switches.                                                       
  6397.  
  6398.   "FTP Extensions for Variable Protocol Specification", S. Ostermann, M. 
  6399.   Allman, 08/21/1997, <draft-allman-ftp-variable-05.txt>                   
  6400.  
  6401.     The specification for the File Transfer Protocol assumes that the
  6402.         underlying network protocols use a 32-bit network address and a
  6403.         16-bit transport address (specifically IP version 4 and TCP).  With
  6404.         the deployment of version 6 of the Internet Protocol, network
  6405.         addresses will no longer be 32-bits.  This paper specifies
  6406.         extensions to FTP that will allow the protocol to work over a
  6407.         variety of network and transport protocols.                        
  6408.  
  6409.   "The Safe Response Header Field", K. Holtman, 09/10/1997, 
  6410.   <draft-holtman-http-safe-03.txt>                                         
  6411.  
  6412.        This document defines a HTTP response header field called Safe,
  6413.        which can be used to indicate that repeating a HTTP request is
  6414.        safe.  Such an indication will allow user agents to handle retries
  6415.        of some safe requests, in particular safe POST requests, in a more
  6416.        user-friendly way.                                                  
  6417.  
  6418.   "Advanced Sockets API for IPv6", W. Stevens, M. Thomas, 07/22/1997, 
  6419.   <draft-stevens-advanced-api-04.txt>                                      
  6420.  
  6421.     Specifications are in progress for changes to the sockets API to 
  6422.     support IP version 6 [RFC-2133].  These changes are for TCP and 
  6423.     UDP-based applications and will support most end-user applications in 
  6424.     use today: Telnet and FTP clients and servers, HTTP clients and 
  6425.     servers, and the like.    But another class of applications exists that
  6426.     will also be run under IPv6.  We call these 'advanced' applications and
  6427.     today this includes programs such as Ping, Traceroute, routing daemons,
  6428.     multicast routing daemons, router discovery daemons, and the like.  The
  6429.     API feature typically used by these programs that make them 'advanced' 
  6430.     is a raw socket to access ICMPv4, IGMPv4, or IPv4, along with some 
  6431.     knowledge of the packet header formats used by these protocols.  To 
  6432.     provide portability for applications that use raw sockets under IPv6, 
  6433.     some standardization is needed for the advanced API features.    There 
  6434.     are other features of IPv6 that some applications will need to access: 
  6435.     interface identification (specifying the outgoing interface and 
  6436.     determining the incoming interface) and IPv6 extension headers that are
  6437.     not addressed in [RFC-2133]: Hop-by-Hop options, Destination options, 
  6438.     and the Routing header (source                                         
  6439.  
  6440.   "NNTP LIST Additions", B. Hernacki, 07/16/1997, 
  6441.   <draft-hernacki-nntplist-02.txt>                                         
  6442.  
  6443.     This document describes a set of enhancements to the Network News 
  6444.     Transport Protocol [NNTP-977] that allows extended server specific 
  6445.     information to be obtained by the client.   These enhancements will be 
  6446.     made as new arguments to the existing LIST verb described in the NNTP 
  6447.     protocol [NNTP-977].     The availability of the extensions described 
  6448.     here will be advertised by the server using the extension 
  6449.     negotiation-mechanism described in the new NNTP protocol specification 
  6450.     currently being developed [NNTP-NEW].                                  
  6451.  
  6452.   "Wrapping MIME Objects:  Application/MIME", Dave Crocker, L. Lundblade, 
  6453.   J. Zawinski, 07/25/1997, <draft-crocker-wrap-02.txt>                     
  6454.  
  6455.     MIME permits labeling and aggregating objects into complex hierarchies.
  6456.     Support for MIME mechanisms is not universal although it is growing 
  6457.     quickly.  Consequently gateways often are required to translate 
  6458.     portions of a MIME object into its constituent pieces, as independent 
  6459.     attachments.                                                           
  6460.  
  6461.   "Payload Format for HTTP Encoding in RTP", B. Aboba, 01/06/1997, 
  6462.   <draft-aboba-rtp-http-02.txt>                                            
  6463.  
  6464.     This document specifies a payload format for use in encoding HTTP 
  6465.     within RTP. This payload format can be used for unreliable multicasting
  6466.     of resources such as Web pages, stock tickers, etc.  As with other RTP 
  6467.     applications, receiver feedback and group membership information is 
  6468.     provided via RTCP.  This specification is not expected to be used with 
  6469.     unicast, since unicast applications will instead use HTTP over TCP.    
  6470.  
  6471.   "Universal Format for Logger Messages", J. Abela, 07/22/1997, 
  6472.   <draft-abela-ulm-02.txt>                                                 
  6473.  
  6474.     This document presents a format to describe system events for logging 
  6475.     purpose.  Some of the features presented here are already in use with 
  6476.     the common syslog facility, but most of them are lost in the crowd of 
  6477.     syslog format freedom.                                                 
  6478.  
  6479.   "The Multicast Dissemination Protocol (MDP) Framework", W. Dang, Joseph 
  6480.   Macker, 06/06/1997, <draft-macker-mdp-framework-02.txt>                  
  6481.  
  6482.     This document outlines a simple protocol framework for reliable 
  6483.     multicast dissemination of data files. The general framework was 
  6484.     originally developed and used by the Image Multicaster (IMM) 
  6485.     application within the Internet MBone for dissemination of satellite 
  6486.     imagery.  This document describes the more general use of the protocol 
  6487.     framework as a reliable bulk file transfer technique.  We discuss the 
  6488.     present operational modes, some performance issues, and the basic 
  6489.     application data units (ADUs) used.  This is not intended to be a 
  6490.     detailed protocol specification document, but rather a broad 
  6491.     description of the basic protocol features and a discussion of issues. 
  6492.     Further detailed description of the protocol implementation may be 
  6493.     provided in future documents.                                          
  6494.  
  6495.   "Network Data Management Protocol", D. Hitz, R. Stager, 09/10/1997, 
  6496.   <draft-stager-pdc-netapp-backup-04.txt>                                  
  6497.  
  6498.           The Network Data Management Protocol (NDMP) is an open protocol
  6499.           for enterprise-wide network based backup. The NDMP architecture
  6500.           allows network attached storage vendors  to ship NDMP compliant
  6501.           file servers which can be used by any NDMP-compliant backup
  6502.           administration application. This same architecture is also used
  6503.           for network-attached backup devices, such as tape drives and
  6504.           tape libraries.                                                  
  6505.  
  6506.   "Interoperability Rules for Multicast Routing Protocols", D. Thaler, 
  6507.   03/26/1997, <draft-thaler-multicast-interop-01.txt>                      
  6508.  
  6509.     The rules described in this document will allow efficient 
  6510.     interoperation among multiple independent multicast routing domains.  
  6511.     Specific instantiations of these rules are given for the DVMRP, MOSPF, 
  6512.     PIM-DM, PIM-SM, and CBT multicast routing protocols, as well as for 
  6513.     IGMP-only links.                                                       
  6514.  
  6515.   "DHCP Options for Novell Directory Services", D. Provan, 10/23/1997, 
  6516.   <draft-provan-dhcp-options-dir-serv-02.txt>                              
  6517.  
  6518.         This document defines three new DHCP options for delivering
  6519.         configuration information to clients of the Novell Directory
  6520.         Services. The first option carries a list of NDS servers. The 
  6521.     second
  6522.         option carries the name of the client's NDS tree. The third carries
  6523.         the initial NDS context. These three options provide an NDS client
  6524.         with enough information to connect to an NDS tree without manual
  6525.         configuration of the client.                                       
  6526.  
  6527.   "Uniform Resource Locators (URL): Generic Syntax and Semantics", Tim 
  6528.   Berners-Lee, Larry Masinter, R. Fielding, 10/22/1997, 
  6529.   <draft-fielding-url-syntax-09.txt>                                       
  6530.  
  6531.     A Uniform Resource Locator (URL) is a compact string representation
  6532.        of a location for use in identifying an abstract or physical
  6533.        resource.  This document defines the general syntax and semantics
  6534.        of URLs, including both absolute and relative locators, and
  6535.        guidelines for their use; it revises and replaces the generic
  6536.        definitions in RFC 1738 and RFC 1808.                               
  6537.  
  6538.   "NNTP Full-text Search Extension", B. Hernacki, N. Ballou, 09/19/1997, 
  6539.   <draft-ballou-nntpsrch-04.txt>                                           
  6540.  
  6541.     This document describes a set of enhancements to the Network News
  6542.        Transport Protocol [NNTP-977] that allows full-text searching of
  6543.        news articles in multiple newsgroups.  The proposed SEARCH command
  6544.        supports functionality similar to the [IMAP4] SEARCH command, minus
  6545.        user specific search keys (i.e., ANSWERED, DRAFT, FLAGGED, KEYWORD,
  6546.        NEW, OLD, RECENT, SEEN) and minus search keys based on headers that
  6547.        do not exist in news (i.e., CC, BCC, TO).
  6548.     
  6549.        The availability of the extensions described here will be advertised
  6550.        by the server using the extension negotiation-mechanism described in
  6551.        the new NNTP protocol specification currently being developed [NNTP-
  6552.        NEW].                                                               
  6553.  
  6554.   "POP3 AUTHentication command", J Myers, 10/28/1997, 
  6555.   <draft-myers-sasl-pop3-02.txt>                                           
  6556.  
  6557.     This document defines the optional AUTH command to POP3 [POP3], for
  6558.        indicating an authentication mechanism to the server, performing an
  6559.        authentication protocol exchange, and optionally negotiating a
  6560.        security layer for subsequent protocol interactions.  This extension
  6561.        is a profile of the Simple Authentication and Session Layer [SASL]. 
  6562.  
  6563.   "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels", Brian 
  6564.   Carpenter, C. Jung, 09/22/1997, <draft-carpenter-ipng-6over4-03.txt>     
  6565.  
  6566.        This memo specifies the frame format for transmission of IPv6 [IPV6]
  6567.        packets and the method of forming IPv6 link-local addresses over 
  6568.     IPv4
  6569.        domains.  It also specifies the content of the Source/Target Link-
  6570.        layer Address option used in the Router Solicitation, Router
  6571.        Advertisement, Neighbor Solicitation, and Neighbor Advertisement
  6572.        and Redirect messages, when those messages are transmitted on an
  6573.        IPv4 network.
  6574.      
  6575.        The motivation for this method is to allow isolated IPv6 hosts,
  6576.        located on a physical link which has no directly connected IPv6
  6577.        router, to become fully functional IPv6 hosts by using an IPv4
  6578.        domain, preferably supporting IPv4 multicast, as their virtual local
  6579.        link.
  6580.      
  6581.        Originally submitted to the IPNG WG, this draft will be discussed in
  6582.        the NGTRANS WG, ngtrans[-request]@sunroof.Eng.Sun.COM.              
  6583.  
  6584.   "PF_KEY Key Management API, Version 2", D. McDonald, B. Phan, C. Metz, 
  6585.   09/10/1997, <draft-mcdonald-pf-key-v2-04.txt>                            
  6586.  
  6587.        A generic key management API that can  be  used  not  only  for  IP
  6588.        Security  [Atk95a]  [Atk95b]  [Atk95c]  but  also  for  other 
  6589.     network
  6590.        security services is presented in this document.  Version 1  of  
  6591.     this
  6592.        API  was  implemented  inside 4.4-Lite BSD as part of the U. S. 
  6593.     Naval
  6594.        Research Laboratory's freely distributable and usable IPv6 and  
  6595.     IPsec
  6596.        implementation[AMPMC96].   It  is  documented here for the benefit 
  6597.     of
  6598.        others who might also adopt and use the API, thus providing 
  6599.     increased
  6600.        portability  of  key  management  applications  (e.g. a manual 
  6601.     keying
  6602.        application,  an  ISAKMP  daemon,  a  GKMP  daemon  [HM97a,HM97b],  
  6603.     a
  6604.        Photuris daemon, or a SKIP certificate discovery protocol daemon).  
  6605.  
  6606.   "Label Switching: Label Stack Encodings", D. Farinacci, Tony Li, A. 
  6607.   Conta, Y Rekhter, Dan Tappan, E. Rosen, G. Fedorkow, 08/21/1997, 
  6608.   <draft-rosen-tag-stack-03.txt>                                           
  6609.  
  6610.     'Multi-Protocol Label Switching (MPLS)' [1,2,9] requires a set of
  6611.        procedures for augmenting network layer packets with 'label stacks'
  6612.        (sometimes called 'tag stacks'), thereby turning them into 'labeled
  6613.        packets'.  Routers which support MPLS are known as 'Label Switching
  6614.        Routers', or 'LSRs'.  In order to transmit a labeled packet on a
  6615.        particular data link, an LSR must support an encoding technique
  6616.        which, given a label stack and a network layer packet, produces a
  6617.        labeled packet.  This document specifies the encoding to be used by
  6618.        an LSR in order to transmit labeled packets on PPP data links and on
  6619.        LAN data links.  This document also specifies rules and procedures
  6620.        for processing the various fields of the label stack encoding.      
  6621.  
  6622.   "A Simple IP Security API Extension to BSD Sockets", D. McDonald, 
  6623.   03/20/1997, <draft-mcdonald-simple-ipsec-api-01.txt>                     
  6624.  
  6625.     In order to take advantage of the IP Security Architecture [Atk95], an 
  6626.     application should be able to tell the system what IP-layer security 
  6627.     services it needs to function with some degree of confidence.   A 
  6628.     simple API that also allows simple security association policy to be 
  6629.     set is presented here.  This document descends from earlier work 
  6630.     performed in the U. S. Naval Research Laboratory's IPv6 and IP security
  6631.     implementation [AMPMC96].                                              
  6632.  
  6633.   "The Weak Authentication and Tracing Option", Don Eastlake, 06/02/1997, 
  6634.   <draft-eastlake-weak-ato-01.txt>                                         
  6635.  
  6636.     The packet switched nature of the Internet Protocol (IP) provides no 
  6637.     inherent method to assure that a packet has been issued with a source 
  6638.     address authorized for use by the sender and no inherent method to 
  6639.     trace the actual source of a packet.  These characteristics make it 
  6640.     difficult to take effective action concerning injurious packets which 
  6641.     may have originated, by accident or maliciously, virtually anywhere in 
  6642.     the Internet.                                                          
  6643.     A lightweight IP level option is proposed that provides (1) some 
  6644.     assurance that packets are authorized by a host along the path routed 
  6645.     through when the packet's source address is used as a destination 
  6646.     address, and (2) limited statistical tracing information such that, if 
  6647.     many bad packets are logged, the path to their source will usually be 
  6648.     revealed.  This would provide significantly improved protection against
  6649.     packet level abuse.                                                    
  6650.  
  6651.   "Representing the Dublin Core within X.500, LDAP and CLDAP", J. Knight, 
  6652.   M. Hamilton, R. Iannella, 07/28/1997, <draft-hamilton-dcxl-02.txt>       
  6653.  
  6654.     The Dublin Core is a simple resource description format which arose out
  6655.     of a loose grouping of 'librarians, archivists, humanities scholars and
  6656.     geographers, as well as standards makers in the Internet, Z39.50 and 
  6657.     Standard Generalized Markup Language (SGML) communities' [1].          
  6658.     This document describes a mapping from the abstract model of the Dublin
  6659.     Core to the X.500 [2], LDAP [3], and CLDAP [4] directory service 
  6660.     protocols.                                                             
  6661.  
  6662.   "Enhanced Communications Transport Service Definition", D. Kim, 
  6663.   08/21/1997, <draft-kim-jtc1-sc6-ects-02.txt>                             
  6664.  
  6665.     This memo is the final Committee Draft of the Enhanced Transport
  6666.       Service Definition under development within ISO/IEC JTC1/SC6/WG7 
  6667.     since
  6668.       last several years in order to provide to the upper-layer 
  6669.     applications
  6670.       enhanced transport services over the current OSI transport service;
  6671.       major enhancements include multicast services and enhanced QoS.
  6672.      
  6673.       This memo is distributed to possibly interested grops within IETF,
  6674.       especially to experts in Transport Area, to make noticed the efforts
  6675.       being made within SC6 to come up with a new transport service
  6676.       definition meeting the wide range of requirements of the both current
  6677.       and future multimedia multicast applications. It is to be noted that
  6678.       a protocol maned ECTP(Enhanced Communications Transport Protocol)
  6679.       supporting this ECTS is also under development within SC6 and will be
  6680.       made public in the near future.
  6681.      
  6682.       Experts interested in this topic might compare the services defined 
  6683.     by
  6684.       ECTS with those provided by more known protocols including RTP, MTP,
  6685.       RMP, and RAMP. The ultimate apparent objective of ECTS is the
  6686.       multimedia multicast transport service with varying degrees of
  6687.       reliability and multicast QoS.                                       
  6688.  
  6689.   "Architecture of the Resource Reservation Service for the Commercial 
  6690.   Internet", M. Suzuki, 10/14/1997, <draft-suzuki-res-resv-svc-arch-02.txt>
  6691.  
  6692.     The purpose of this document is to clarify the architecture that
  6693.        should be used for the resource reservation service for the
  6694.        commercial Internet.
  6695.      
  6696.        First, this document explains the basis of the tariff for current
  6697.        telecommunication and Internet services.  Then it clarifies problems
  6698.        in the billing for Internet service, and describes how billing can 
  6699.     be
  6700.        improved by using the resource reservation setup protocol.  Finally,
  6701.        it also studies technical and application models for a commercial
  6702.        resource reservation service model, and clarifies an architecture 
  6703.     for
  6704.        the resource reservation setup protocol.                            
  6705.  
  6706.   "LZS Payload Compression Transform for ESP", R. Monsour, M. Sabin, 
  6707.   03/26/1997, <draft-sabin-lzs-payload-01.txt>                             
  6708.  
  6709.     This memo proposes a 'payload compression transform' based on the LZS 
  6710.     compression algorithm.  The transform can be used to compress the 
  6711.     payload field of an IP datagram that uses the Encapsulating Security 
  6712.     Payload (ESP) format.  The compression transform proposed here is 
  6713.     stateless, meaning that a datagram can be decompressed independently of
  6714.     any other datagram.  Compression is performed prior to the encryption 
  6715.     operation of ESP, which has the side benefit of reducing the amount of 
  6716.     data that must be encrypted.                                           
  6717.     This memo anticipates a forthcoming ESP document that will supercede 
  6718.     [Atkins96].  The forthcoming document will allow for ESP payloads to be
  6719.     compressed via transforms such as the one described in this memo.      
  6720.  
  6721.   "RMFP: A Reliable Multicast Framing Protocol", Jon Crowcroft, Zheng Wang,
  6722.   A. Ghosh, C. Diot, 03/20/1997, <draft-crowcroft-rmfp-01.txt>             
  6723.  
  6724.     There has been considerable interest in reliable multicast, and a 
  6725.     number of reliable multicast transport applications and systems have 
  6726.     been built in the past years.                                          
  6727.  
  6728.   "Simple Unified Networking", Masataka Ohta, 03/26/1997, 
  6729.   <draft-ohta-sun-01.txt>                                                  
  6730.  
  6731.     The concept of LIS for IP over ATM causes a topology mismatch between 
  6732.     the link and the internetworking layer. While it introduces some 
  6733.     inefficiency with CATENET based operation, it is not so much a problem 
  6734.     unless we try to solve this minor problem.      Short-cutting attempts 
  6735.     such as NHRP can't solve the inefficiency issue at all even though, or,
  6736.     just because, it utterly destroys the CATENET model, which resulted in 
  6737.     inelegant modifications of existing protocols, which, in turn, causes 
  6738.     scalability problems.     Moreover, the creation of short-cut VCs 
  6739.     itself suffers a scalability issue.    But, CSRs (Cell Switching 
  6740.     Routers), or RSVP-signaled ATM switches, make it possible to have 
  6741.     end-to-end cell-by-cell relaying over IP routers. That is, there is no 
  6742.     reason to have LISes and there is no inefficiency     The way to go for
  6743.     the Internet is Simple Unified Networking with the CATENET model.      
  6744.  
  6745.   "Securing FTP with TLS", E. Murray, P. Ford-Hutchinson, T. Hudson, 
  6746.   08/01/1997, <draft-murray-auth-ftp-ssl-02.txt>                           
  6747.  
  6748.        This document describes a mechanism that can be used by FTP clients
  6749.        and servers to implement security and authentication using the TLS
  6750.        protocol defined by the IETF TLS working group and the extensions to
  6751.        the FTP protocol defined by the IETF CAT working group.  It 
  6752.     describes
  6753.        the subset of the extensions that are required and the parameters to
  6754.        be used; discusses some of the policy issues that clients and 
  6755.     servers
  6756.        will need to take; considers some of the implications of those
  6757.        policies and discusses some expected behaviours of implementations 
  6758.     to
  6759.        allow interoperation.
  6760.      
  6761.        TLS is not the only mechanism for securing file transfer, however it
  6762.        does offer some of the following positive attributes:-
  6763.     
  6764.           - Flexible security levels.  TLS can support privacy, integrity,
  6765.           authentication or some combination of all of these.  This allows
  6766.           clients and servers to dynamically, during a session, decide on
  6767.           the level of security required for a particular data transfer,
  6768.      
  6769.           - Formalised public key management.  By use of X.509 public
  6770.           certificates during the authentication phase, certificate
  6771.           management can be built into a central function.  Whilst this may
  6772.           not be desirable for all uses of secured file transfer, it offers
  6773.           advantages in certain structured environments such as access to
  6774.           corporate data sources.
  6775.      
  6776.           - Co-existence and interoperation with authentication mechanisms
  6777.           that are already in place for the HTTPS protocol.  This allows 
  6778.     web
  6779.           browsers to incorporate secure file transfer using the same
  6780.           infrastructure that has been set up to allow secure web browsing.
  6781.      
  6782.        The TLS protocol is a development of the Netscape Communication
  6783.        Corporation's SSL protocol and this document can be used to allow 
  6784.     the
  6785.        FTP protocol to be used with either SSL or TLS.  The actual protocol
  6786.        used will be decided by the negotiation of the protected session by
  6787.        the TLS/S                                                           
  6788.  
  6789.   "Key Derivation for Authentication, Integrity, and Privacy", M. Horowitz,
  6790.   03/27/1997, <draft-horowitz-key-derivation-01.txt>                       
  6791.  
  6792.     Recent advances in cryptography have made it desirable to use longer 
  6793.     cryptographic keys, and to make more careful use of these keys.  In 
  6794.     particular, it is considered unwise by some cryptographers to use the 
  6795.     same key for multiple purposes.  Since most cryptographic-based systems
  6796.     perform a range of functions, such as authentication, key exchange, 
  6797.     integrity, and encryption, it is desirable to use different 
  6798.     cryptographic keys for these purposes.                                 
  6799.     This document does not define a particular protocol, but defines a set 
  6800.     of cryptographic transformations for use with arbitrary network 
  6801.     protocols and block cryptographic algorithm.                           
  6802.  
  6803.   "Selectively Reliable Transport Protocol", Mark Pullen, V. Laviano, 
  6804.   08/04/1997, <draft-laviano-srtp-02.txt>                                  
  6805.  
  6806.     This memo describes a protocol for selectively reliable transmission of
  6807.     Distributed Interactive Simulation (DIS) data in a wide-area multicast 
  6808.     environment. The Selectively Reliable Transmission Protocol (SRTP) 
  6809.     operates in three distinct modes: best-effort multicast, reliable 
  6810.     multicast using negative acknowledgements with a NAK suppression 
  6811.     mechanism to avoid congestion at the sender, and lightweight reliable 
  6812.     transaction-oriented unicast. SRTP is designed to run in user space and
  6813.     form a sublayer between applications and the kernel-level Internet 
  6814.     protocol stack.                                                        
  6815.  
  6816.   "The RWhois Version 1.x Uniform Resource Locator", Scott Williamson, M. 
  6817.   Mealling, 08/02/1997, <draft-mealling-rwhoisurl-01.txt>                  
  6818.  
  6819.     RWhois is an Internet directory access protocol, defined in RFC1714 [1]
  6820.     and RFC2167 [3]. This document describes a format for an RWhois Uniform
  6821.     Resource Locator (URL) that will allow Internet clients to have direct 
  6822.     access to the RWhois protocol. An RWhois URL will represent a single 
  6823.     query to an RWhois server.                                             
  6824.  
  6825.   "Videotex URL Specification", D. Mavrakis, H. Layec, K. Kartmann, 
  6826.   05/20/1997, <draft-mavrakis-videotex-url-spec-01.txt>                    
  6827.  
  6828.     A new URL scheme, 'videotex' is defined. It allows videotex client 
  6829.     software or terminals to connect to videotex services compliant to the 
  6830.     ITU-T and ETSI videotex standards, including among others:             
  6831.     - ITU/T Recommendation T.101: International Interworking for Videotex 
  6832.     [3]  - ETS 300 072: Videotex presentation layer protocol, videotex 
  6833.     presentation layer data syntax [7]. - ETS 300 073: Videotex 
  6834.     presentation layer protocol, Geometric display [12].   - ETS 300 076: 
  6835.     Videotex Terminal Facility Identifier (TFI) [14]  - ETS 300 149: 
  6836.     Videotex presentation layer protocol, Audio Syntax [16].  - ETS 300 
  6837.     177: Videotex presentation layer protocol, Photographic Syntax [15].  -
  6838.     ANSI X3.110 - CSA T500: Videotex/Teletext Presentation Level Protocol 
  6839.     Syntax [17].                 The well-known port number 516 has been 
  6840.     assigned by IANA to the videotex protocol [2].                         
  6841.  
  6842.   "Internationalization of Domain Names", M. Duerst, 07/30/1997, 
  6843.   <draft-duerst-dns-i18n-01.txt>                                           
  6844.  
  6845.     Internet domain names are currently limited to a very restricted 
  6846.     character set. This document proposes the introduction of a new 
  6847.     'zero-level' domain (ZLD) to allow the use of arbitrary characters from
  6848.     the Universal Character Set (ISO 10646/Unicode) in domain names.  The 
  6849.     proposal is fully backwards compatible and does not need any changes to
  6850.     DNS.                                                                   
  6851.  
  6852.   "Flow Grouping For Reducing Reservation Requirements for Guaranteed Delay
  6853.   Service", R. Guerin, S. Rampal, 07/17/1997, 
  6854.   <draft-rampal-flow-delay-service-01.txt>                                 
  6855.  
  6856.     The purpose of this document is to illustrate when and how flow 
  6857.     aggregation can be of benefit in the context of the Guaranteed Service.
  6858.     Specifically, it identifies simple cases and provides generic rules for
  6859.     when grouping of flows allows a reduction in the amount of resources 
  6860.     (bandwidth) needed to ensure the deterministic Guaranteed Service delay
  6861.     bounds of all flows.  The benefits of grouping should be especially of 
  6862.     interest to, say, Internet Service Providers, wishing to interconnect 
  6863.     sites with Guaranteed Service flows.  In particular, this document 
  6864.     shows that in the case of flows with identical traffic characteristics 
  6865.     and requirements, e.g., Internet voice, grouping of flows is ALWAYS 
  6866.     beneficial.                                                            
  6867.     This technique is not intended for IETF standardization and is being 
  6868.     submitted for informational purposes only.                             
  6869.  
  6870.   "Originator-Info Message Header", C Newman, 08/28/1997, 
  6871.   <draft-newman-msgheader-originfo-02.txt>                                 
  6872.  
  6873.          This proposal is an attempt to provide a standard header to
  6874.          indicate information about the message originator without implying
  6875.          that there is a deliverable mailbox or mandating that internal
  6876.          network information be revealed.                                  
  6877.  
  6878.   "Date and Time on the Internet", C Newman, 01/27/1997, 
  6879.   <draft-newman-datetime-01.txt>                                           
  6880.  
  6881.     Date and time formats cause a lot of confusion and interoperability 
  6882.     problems on the Internet.  This document will address many of the 
  6883.     problems encountered and make recommendations to improve consistancy 
  6884.     and interoperability when representing and using date and time in 
  6885.     Internet protocols.                                                    
  6886.  
  6887.   "FTP Security Considerations", S. Ostermann, M. Allman, 08/21/1997, 
  6888.   <draft-allman-ftp-sec-consider-02.txt>                                   
  6889.  
  6890.     The specification for the File Transfer Protocol contains a number of 
  6891.     mechanisms that can be used to compromise network security.  The FTP 
  6892.     specification allows a client to instruct a server to transfer files to
  6893.     a third machine.  This third-party mechanism, known as proxy FTP, 
  6894.     causes a well known security problem.  The FTP specification also 
  6895.     allows an unlimited number of attempts at entering a user's password.  
  6896.     This allows brute force 'password guessing' attacks.  This document 
  6897.     provides suggestions for system administrators and those implementing 
  6898.     FTP servers that will decrease the security problems associated with 
  6899.     FTP.                                                                   
  6900.  
  6901.   "Draft Specifications for Administration and Management of gTLDs", Dave 
  6902.   Crocker, 12/26/1996, <draft-iahc-gtldspec-00.txt>                        
  6903.  
  6904.     The International Ad Hoc Committee (IAHC) was formed at the initiative 
  6905.     of the Internet Society, and at the request of the Internet Assigned 
  6906.     Numbers Authority (IANA).  IANA has responsibility for the maintenance 
  6907.     of core administrative tables for Internet services, including 'top 
  6908.     level' domain names (TLD) and the delegation of their maintenance to 
  6909.     appropriate agencies.  The IAHC is tasked with developing 
  6910.     administration and management enhancements for the general class of 
  6911.     TLDs that have been called 'international'.                            
  6912.  
  6913.   "NAT extension for existing "external" networks", G. Gloesener, 
  6914.   12/30/1996, <draft-gloesener-nat-ext-00.txt>                             
  6915.  
  6916.     The main use of NAT is to connect an existing internal network via an 
  6917.     ISP to the Internet. The current NAT RFC1631 supposes that the network 
  6918.     number used for the translation is not existing physically on any 
  6919.     network. This does not work in some circumstances where the router 
  6920.     connected to the ISP line is not under control of the user. This 
  6921.     implies that the network where the NAT router is connected to, has the 
  6922.     same network number than the one used by NAT.                          
  6923.  
  6924.   "Multiprotocol Extensions for BGP", Dimitry Haskin, J. Stewart, 
  6925.   12/30/1996, <draft-stewart-bgp-multiprotocol-00.txt>                     
  6926.  
  6927.     This document outlines a proposal for a BGP Version 5 (BGP5) which has 
  6928.     the ability to carry routing information for a variety of network 
  6929.     protocols.  The proposed BGP modifications are intended to be simple 
  6930.     enough to be easily added to the existing BGP implementations and, at 
  6931.     the same time, provide for a longer than 16-bit AS number space.      
  6932.     This document only describes BGP5 support for IPv4 and IPv6 networks.  
  6933.  
  6934.   "Proposal of a suggested protocol for an interactive, real-time 
  6935.   cryptographic 'key' server", D. Merriman, 01/03/1997, 
  6936.   <draft-merriman-realtime-key-00.txt>                                     
  6937.  
  6938.     With the increase in privacy-enabling cryptographic software, there 
  6939.     exists the growing problem of verification of the 'validity' of a 
  6940.     cryptographic 'key'. That is, the recipient of (for example) a 
  6941.     PGP-signed email message from an unknown person generally has no ready,
  6942.     convenient means to verify that the 'signature' on the message actually
  6943.     belongs to the sender. To verify the relationship between a 
  6944.     cryptographic 'key' and an identity (real or anonymous), it is 
  6945.     necessary for an individual to contact one of several existing 'manual'
  6946.     keyservers as a separate process, request the key (if it exists on that
  6947.     keyserver), and retrieve it before being able to use it for any 
  6948.     reference or validation purposes.          This draft is meant to 
  6949.     propose a protocol/system that would both enable the automatic 
  6950.     retrieval of cryptographic keys, and the exchange of keys between 
  6951.     servers (both new keys, and those deleted through revocation 
  6952.     certificates). This proposal could be extended to allow retrieval of 
  6953.     cryptographic certificates and/or 'credentials' with relatively minor 
  6954.     difficulty.                                                            
  6955.  
  6956.   "Multiprotocol Extensions for BGP-4", D Katz, Y Rekhter, T. Bates, R. 
  6957.   Chandra, 07/09/1997, <draft-bates-bgp4-multiprotocol-03.txt>             
  6958.  
  6959.     Currently BGP-4 [BGP-4] is capable of carrying routing information only
  6960.     for IPv4 [IPv4]. This document defines extensions to BGP-4 to enable it
  6961.     to carry routing information for multiple Network Layer protocols 
  6962.     (e.g., IPv6, IPX, etc...). The extensions are backward compatible - a 
  6963.     router that supports the extensions can interoperate with a router that
  6964.     doesn't support the extensions.                                        
  6965.  
  6966.   "Using BGP Without Consuming a Unique ASN", J. Stewart, E. Chen, 
  6967.   01/03/1997, <draft-stewart-bgp-without-as-00.txt>                        
  6968.  
  6969.     The number of organizations that have more than one Internet connection
  6970.     is increasing significantly with time.  In a substantial number of 
  6971.     these cases, an organization's multiple connections are from the same 
  6972.     ISP; this type of multi-homing is localized to the organization and its
  6973.     single provider, so a globally unique ASN should not be needed.  
  6974.     However, many ISPs can only support their customers' reliability and 
  6975.     load-sharing requirements by using BGP, which DOES require an ASN.  
  6976.     Since the needs of the ISP and its multi-homed customer are contrary to
  6977.     the Internet's need to allocate the ASN space sensibly, this is a 
  6978.     problem.  A solution to this problem has been proposed which makes use 
  6979.     of private ASNs, but it has several disadvantages.  This paper 
  6980.     documents the existing solution and describes its disadvantages, then 
  6981.     presents another solution which doesn't share the same disadvantages.  
  6982.  
  6983.   "Guidelines and Process for new URL Schemes", Harald Alvestrand, Larry 
  6984.   Masinter, D. Zigmond, 03/26/1997, <draft-masinter-url-process-01.txt>    
  6985.  
  6986.     A Uniform Resource Locator (URL) is a compact string representation of 
  6987.     the location for a resource that is available via the Internet.  [RFC 
  6988.     URL-SYNTAX] defines the general syntax and semantics of URLs.  This 
  6989.     document provides guidelines for the definition of new URL schemes and 
  6990.     describes the process by which they are registered.                    
  6991.  
  6992.   "Forcing HTTP/1.1 proxies to revalidate responses", J Mogul, 05/28/1997, 
  6993.   <draft-mogul-http-revalidate-01.txt>                                     
  6994.  
  6995.     The HTTP/1.1 specification [1] currently defines a ``proxy-revalidate''
  6996.     Cache-control directive, which forces a proxy to revalidate a stale 
  6997.     response before using it in a reply.  There is no mechanism defined 
  6998.     that forces a proxy, but not an end-client, to revalidate a fresh 
  6999.     response.  The lack of such a mechanism is due to an error in drafting 
  7000.     RFC2068, and appears to create problems for use of the Authorization 
  7001.     header, the Digest Access Authentication extension [2], the State 
  7002.     Management Mechanism [3], and several other proposed extensions.  This 
  7003.     document discusses the problem and several possible solutions, and 
  7004.     proposes to add a new ``s-maxage'' directive as the best available 
  7005.     solution.                                                              
  7006.  
  7007.   "Security Industry Internet Protocol for Alarm Transmission (SIIPAT)", S.
  7008.   Ryckman, 01/08/1997, <draft-rfced-info-ryckman-01.txt>                   
  7009.  
  7010.     This document suggests a method for delivering alarm information over 
  7011.     the Internet.  All communication shall use an encryption algorithm for 
  7012.     transmission of the data.  An immediate response from the host will be 
  7013.     used for verification of receipt of the message.                       
  7014.     This transmission method may be use as a backup transmission method to 
  7015.     traditional dial-up or leased line methods, or as a primary 
  7016.     transmission method with traditional methods becomming the backup.     
  7017.     Due to the required security of the data being transmitted, the 
  7018.     encryption algorithm used will only be released on a need to know basis
  7019.     to software developers in the Alarm/Security Industry.  A 
  7020.     non-disclosure agreement will be required.  Terms and conditions of the
  7021.     licensing will depend on the intended purpose for use and may require a
  7022.     non-competition agreement or licensing fees.                           
  7023.     The Internet Assigned Numbers Authority (IANA) has assigned port 1733 
  7024.     for the registered use of SIIPAT transmissions.                        
  7025.  
  7026.   "The mailto URL scheme", Larry Masinter, Paul Hoffman, J. Zawinski, 
  7027.   10/21/1997, <draft-hoffman-mailto-url-02.txt>                            
  7028.  
  7029.     This document defines the format of Uniform Resource Locators (URL)
  7030.     for designating electronic mail addresses. It is one of a suite of
  7031.     documents which replace RFC 1738, 'Uniform Resource Locators', and RFC
  7032.     1808, 'Relative Uniform Resource Locators'. The syntax of 'mailto'
  7033.     URLs from RFC 1738 is extended to allow creation of more RFC 822
  7034.     messages by allowing the URL to express additional header and body
  7035.     fields.                                                                
  7036.  
  7037.   "A FTP URL Format", J. Casey, 01/09/1997, <draft-casey-url-ftp-00.txt>   
  7038.  
  7039.     This document defines the format of Uniform Resource Locators (URL) for
  7040.     the File Transfer Protocol (FTP) using the general URL syntax defined 
  7041.     in RFC xxxx, 'Uniform Resource Locators (URL)'.                        
  7042.     It is a one of a suite of documents which replace RFC 1738, 'Uniform 
  7043.     Resource Locators', and RFC 1808, 'Relative Uniform Resource Locators'.
  7044.  
  7045.   "MIME media-types for Print Formats", R. Lutz, 01/09/1997, 
  7046.   <draft-lutz-print-types-00.txt>                                          
  7047.  
  7048.     This memo defines media-type designators for various printer control 
  7049.     file formats which are popularly used in the industry, and proposes a 
  7050.     means to correlate the printer interpreter types as specified in the 
  7051.     Printer MIB (RFC-1759).                                                
  7052.  
  7053.   "Tag Switching Architecture - Overview", D Katz, D. Farinacci, Bruce 
  7054.   Davie, George Swallow, Y Rekhter, E. Rosen, 08/05/1997, 
  7055.   <draft-rekhter-tagswitch-arch-01.txt>                                    
  7056.  
  7057.     This document provides an overview of tag switching. Tag switching is a
  7058.     way to combine the label-swapping forwarding paradigm with network 
  7059.     layer routing. This has several advantages. Tags can have a wide 
  7060.     spectrum of forwarding granularities, so at one end of the spectrum a 
  7061.     tag could be associated with a group of destinations, while at the 
  7062.     other a tag could be associated with a single application flow. At the 
  7063.     same time forwarding based on tag switching, due to its simplicity, is 
  7064.     well suited to high performance forwarding. These factors facilitate 
  7065.     the development of a routing system which is both functionally rich and
  7066.     scalable. Finally, tag switching simplifies integration of routers and 
  7067.     ATM switches by employing common addressing, routing, and management 
  7068.     procedures.                                                            
  7069.  
  7070.   "POP3 Service Extensions", D. Rauschenbach, 01/10/1997, 
  7071.   <draft-rauschenbach-pop3-framework-00.txt>                               
  7072.  
  7073.     This memo defines a framework for extending the POP3 service by 
  7074.     defining a means whereby a POP3 server can inform a client as to the 
  7075.     service extensions it supports.                                        
  7076.  
  7077.   "POP3 Service Extensions", D. Rauschenbach, 01/10/1997, 
  7078.   <draft-rauschenbach-pop3-framework-00.txt>                               
  7079.  
  7080.     This memo defines a framework for extending the POP3 service by 
  7081.     defining a means whereby a POP3 server can inform a client as to the 
  7082.     service extensions it supports.                                        
  7083.  
  7084.   "CamCoder Control Protocol", Masataka Ohta, A. Amano, S. Shimojo, H. 
  7085.   Kago, H. Fujiwara, 01/16/1997, <draft-ohta-ccc-video-00.txt>             
  7086.  
  7087.     CCCP (CamCoder Control Protocol) is designed after FTP to be useful to 
  7088.     operate realtime/batch analog/digital video cameras and video/audio 
  7089.     recorders over the Internet.                                           
  7090.  
  7091.   "NICS Network of Identifier and Credential Servers", G. Hoare, 
  7092.   01/17/1997, <draft-hoare-nics-00.txt>                                    
  7093.  
  7094.     NICS is a proposed system which meets the requirements of large-scale, 
  7095.     unique principal identification, for use in conjunction with an 
  7096.     arbitrary set of security systems such as have been proposed by members
  7097.     of the IETF. This proposal outlines the motivation for the development 
  7098.     of NICS, and gives a general description of its internal workings and 
  7099.     interfaces with higher-level protocols.    It should be emphasized up 
  7100.     front that NICS is not a complete security system, nor does it aim to 
  7101.     replace any existing components of the internet which already work. The
  7102.     design draws off the fact that many security systems already have 
  7103.     flexible name schemes, and are therefore considered components which 
  7104.     are used in conjunction with NICS to achieve an improved level of 
  7105.     service, flexibility and reliability, while introducing many desirable 
  7106.     features such as anonymous identifiers, self-optimization, and 
  7107.     low-overhead operation.    For the purpose of initial evaluation, the 
  7108.     remainder of this paper is short and to the point, and requires a 
  7109.     little work on the reader's side to understand the reasoning. 
  7110.     Additional discussion is welcome on the mailing list.                  
  7111.  
  7112.   "The Multicast Attribute Framing Protocol", Ross Finlayson, 01/17/1997, 
  7113.   <draft-finlayson-mafp-00.txt>                                            
  7114.  
  7115.     The Internet has recently seen the emergence of applications that 
  7116.     involve the ongoing transmission, or 'pushing', of structured data from
  7117.     a server to one or more client nodes.  Most current applications send 
  7118.     this data using unicast communications - usually over TCP connections. 
  7119.     However, similar applications can also be implemented using 
  7120.     multicast-based protocols.   Multicast not only improves the 
  7121.     scalability of this particular class of application, but also makes 
  7122.     possible an additional class of application in which the participants 
  7123.     can act as peers - sending data as well as receiving.    This Internet 
  7124.     Draft describes the 'Multicast Attribute Framing Protocol' (MAFP) - a 
  7125.     generic, attribute-based data representation, intended for a wide 
  7126.     variety of multicast-based applications.  It is currently being used to
  7127.     implement the 'multikit' generic multicast session browser 
  7128.     (http://www.lvn.com/multikit).  This draft describes an early version 
  7129.     of MAFP that is likely to undergo substantial changes in the future.  
  7130.     However, it is being described now, in the hope that it will promote 
  7131.     open discussion of this and similar protocols - ideally leading to the 
  7132.     adoption of an open, interoperable                                     
  7133.  
  7134.   "Protocol Independent Multicast-Sparse Mode  (PIM-SM):  Implementation 
  7135.   Document", A. Helmy, 01/20/1997, <draft-helmy-pim-sm-implem-00.txt, .ps> 
  7136.  
  7137.     This document describes the details of the PIM-SM [1,2,3] version 2 
  7138.     implementation for UNIX platforms;  namely SunOS and SGI-IRIX. A 
  7139.     generic kernel model is adopted,  which is protocol independent, 
  7140.     however some supporting functions are added to the kernel for 
  7141.     encapsulation of data packets at user level and decapsulation of PIM 
  7142.     Registers.                  Further, the basic model for the user 
  7143.     level,  PIM daemon (pimd), implementation is described.                
  7144.     Implementation details and code are included in supplementary 
  7145.     appendices.                                                            
  7146.  
  7147.   "Network Element Object MIB (Neo-MIB)", W. Tackabury, 01/20/1997, 
  7148.   <draft-tackabury-neo-mib-00.txt>                                         
  7149.  
  7150.     This memo defines an experimental portion of the scope of the 
  7151.     Management Information Base (MIB) for use with Internet community 
  7152.     network management protocols.  The particular focus of this MIB scope 
  7153.     extension is the presentation and management of objects for network 
  7154.     topology information.   Constructs and encodings for these topology 
  7155.     objects has been specified in a manner consistent with the dictates of 
  7156.     the SNMP Version 2 SMI.                                                
  7157.  
  7158.   "Content Duration MIME Header Definition", G. Vaudreuil, G. Parsons, 
  7159.   07/30/1997, <draft-ema-vpim-dur-01.txt>                                  
  7160.  
  7161.     This document describes the MIME header Content-Duration that is
  7162.           intended for use with any time varying media content (typically
  7163.           audio/* or video/*).  The length of time is represented in 
  7164.     seconds
  7165.           without any units indication..                                   
  7166.  
  7167.   "Toll Quality Voice - 32 kbit/s ADPCM MIME Sub-type Registration", G. 
  7168.   Vaudreuil, G. Parsons, 07/30/1997, <draft-ema-vpim-32kadpcm-01.txt>      
  7169.  
  7170.           This document describes the registration of the MIME sub-type
  7171.           audio/32KADPCM for toll quality audio.  This audio encoding is
  7172.           defined by the ITU-T in Recommendation G.726.  This document 
  7173.     refines
  7174.           an earlier sub-type registration in RFC 1911.
  7175.                                                                            
  7176.  
  7177.   "VPIM Voice Message MIME Sub-type Registration", G. Vaudreuil, G. 
  7178.   Parsons, 07/30/1997, <draft-ema-vpim-vmsg-01.txt>                        
  7179.  
  7180.           This document describes the registration of the MIME sub-type
  7181.           multipart/voice-message for use with the Voice Profile for 
  7182.     Internet
  7183.           Mail (VPIM).  A full description of usage can be found in the 
  7184.     VPIM
  7185.           v2 specification [VPIM2].  This document revises an earlier 
  7186.     sub-type
  7187.           registration in RFC 1911 [VPIM1].
  7188.                                                                            
  7189.  
  7190.   "Network Tuning for Efficiency and Throughput", L. Breit, 01/23/1997, 
  7191.   <draft-breit-ntwrk-tuning-00.txt>                                        
  7192.  
  7193.     Network tuning is usually performed after the network design is 
  7194.     completed, but should also be done at intervals during the life cycle 
  7195.     of the network.  There are four basic areas that directly affect the 
  7196.     efficiency of the network and its associated throughput:    Frame and 
  7197.     packet size optimization  Segmentation avoidance or limitation  
  7198.     Minimization of device delay   Window sizing to avoid degradation    
  7199.     This draft has been written to document for the internet community a 
  7200.     basic overview of network tuning and its benefits.                     
  7201.  
  7202.   "A Distributed MARS Protocol", G. Armitage, 01/23/1997, 
  7203.   <draft-armitage-ion-distmars-spec-00.txt>                                
  7204.  
  7205.     The Server Cache Synchronisation Protocol (SCSP) has been proposed as a
  7206.     general mechanism for synchronising the databases of IP/ATM Servers, 
  7207.     such as those used by NHRP and MARS. This document specifies an 
  7208.     application of SCSP to allow multiple MARS entities to provide fault 
  7209.     tolerance to MARS Clusters.                                            
  7210.  
  7211.   "Certificate Policy and Certification Practice Statement Framework", 
  7212.   Warwick Ford, S. Chokhani, 01/27/1997, <draft-chokhani-cps-00.txt>       
  7213.  
  7214.     This document presents an initial draft of a framework to assist the 
  7215.     writers of X.509 certificate policies or certification practice 
  7216.     statements for certification authorities and public key 
  7217.     infrastructures.  In particular,  the framework identifies a 
  7218.     comprehensive list of topics that potentially (at the writer's 
  7219.     discretion) need to be covered in an X.509 certificate policy or a 
  7220.     certification practice statement.                                      
  7221.  
  7222.   "Survey of Defined Managed Objects for Applications Management", H. 
  7223.   Hazewinkel, 07/21/1997, <draft-hazewinkel-appl-mib-01.txt>               
  7224.  
  7225.     This document was produced as the result of a survey on MIBs related to
  7226.     application management. The goal was to identify overlapping or 
  7227.     duplicated objects and discover problems within the relationships 
  7228.     between those MIBs.                                                    
  7229.  
  7230.   "Network Control Protocol for the Configuration of Mobile Wireless 
  7231.   Beam-formed GPS-Based Networks", S. Bush, S. Jagannath, 01/28/1997, 
  7232.   <draft-bush-ncp-config-00.txt>                                           
  7233.  
  7234.     The Network Control Protocol (NCP) facilitates the configuration and 
  7235.     rapid reconfiguration of mobile wireless beam-formed networks. It 
  7236.     controls the operation of a network of omni-directional packet radios 
  7237.     (orderwire) that overlays the mobile wireless network. Each network 
  7238.     element in this network uses Global Positioning System (GPS) 
  7239.     information to control a beamforming antenna subsystem which provides 
  7240.     for spatial reuse. The GPS information is shared among the network 
  7241.     elements over the orderwire and an optimal topology for the beam-formed
  7242.     links is determined.                                                   
  7243.  
  7244.   "The Definition of Managed Objects for Virtual Network Configuration", S.
  7245.   Bush, S. Jagannath, 01/28/1997, <draft-bush-vnc-mib-00.txt>              
  7246.  
  7247.     This memo defines a portion of the Management Information Base (MIB) 
  7248.     for use with network management protocols in TCP/IP-based internets.  
  7249.     In particular, it describes managed objects used for managing Virtual 
  7250.     Network Configuration (VNC) of the Rapidly Deployable Radio Network 
  7251.     (RDRN) Network Control Protocol (NCP).                                 
  7252.  
  7253.   "The Definition of Managed Objects for the Configuration of Mobile 
  7254.   Wire-less Beamformed GPS-Based Networks", S. Bush, S. Jagannath, 
  7255.   01/28/1997, <draft-bush-rdrn-mib-00.txt>                                 
  7256.  
  7257.     This memo defines a portion of the Management Information Base (MIB) 
  7258.     for use with network management protocols in TCP/IP-based internets.  
  7259.     In particular, it describes managed objects used for managing the 
  7260.     Rapidly Deployable Radio Network (RDRN) Network Control Protocol (NCP).
  7261.  
  7262.   "StarBurst Multicast File Transfer Protocol (MFTP) Specification", K. 
  7263.   Robertson, K. Miller, M. White, A. Tweedly, 02/13/1997, 
  7264.   <draft-miller-mftp-spec-02.txt>                                          
  7265.  
  7266.     The Multicast File Transfer Protocol (MFTP) is a protocol that operates
  7267.     above UDP in the application layer to provide a reliable means for 
  7268.     transferring files from a sender to up to thousands (potentially 
  7269.     millions with network 'aggregators' or relays) of multiple receivers 
  7270.     simultaneously over a multicast group in a multicast IP enabled 
  7271.     network.  The protocol consists of two parts; an administrative 
  7272.     protocol to set up and tear down groups and sessions, and a data 
  7273.     transfer protocol used to send the actual file reliably and 
  7274.     simultaneously to the multiple recipients residing in the group.       
  7275.  
  7276.   "AT&T/Neda's Efficient Short Remote Operations (ESRO) Protocol 
  7277.   Specification Version 1.2", M. Banan, J. Cheng, M. Taylor, 09/11/1997, 
  7278.   <draft-rfced-info-banan-esro-01.txt>                                     
  7279.  
  7280.     This document specifies the service model, the notation and protocol 
  7281.     for Efficient Short Remote Operations (ESRO). The ESRO service is 
  7282.     similar to and is consistent with other Remote Procedure Call services.
  7283.     The emphasis of ESRO service definition and the ESRO protocol is on 
  7284.     efficiency.  ESRO is designed specifically with wireless network (e.g.,
  7285.     CDPD) usage in mind. ESRO protocol provides reliable connectionless 
  7286.     remote operation services on top of UDP (or any other non-reliable 
  7287.     connectionless transport service) with minimum overhead.  ESRO protocol
  7288.     supports segmentation and reassembly, concatenation and separation as 
  7289.     well as multiplexing for service users (applications).            ESRO 
  7290.     allows for trade-offs between efficiency and reliability by specifying 
  7291.     both 2-way hand-shake and 3-way hand-shake based protocols.     
  7292.     Encoding mechanisms for presentation of the parameters of remote 
  7293.     operations are outside the scope of this document.  But, identification
  7294.     (tagging) of the encoding mechanism in use (e.g., XDR, BER, PER) is 
  7295.     supported by ESRO protocol.    A variety of applications can use the 
  7296.     ESRO protocol.  Some early applications using ESRO include efficient 
  7297.     short message submission and delivery, credit card                     
  7298.  
  7299.   "IMAP4 Referrals", M. Gahrns, 04/22/1997, 
  7300.   <draft-gahrns-imap-referrals-02.txt>                                     
  7301.  
  7302.     When dealing with large amounts of users, messages and geographically 
  7303.     dispersed IMAP4 [RFC-2060] servers, it is often desirable to distribute
  7304.     messages amongst different servers within an organization.  For example
  7305.     an administrator may choose to store user's personal mailboxes on a 
  7306.     local IMAP4 server, while storing shared mailboxes remotely on another 
  7307.     server.  This type of configuration is common when it is uneconomical 
  7308.     to store all data centrally due to limited bandwidth or disk resources.
  7309.     Additionally, users may be frequently moved from one IMAP4 server to 
  7310.     another because of hardware failures or organizational changes.        
  7311.     Referrals allow clients to seamlessly access mailboxes that are 
  7312.     distributed across several IMAP4 servers or to transparently connect to
  7313.     an alternate IMAP4 server.                                             
  7314.     A referral mechanism can provide efficiencies over the alternative 
  7315.     'proxy method', in which the local IMAP4 server contacts the remote 
  7316.     server on behalf of the client, and then transfers the data from the 
  7317.     remote server to itself, and then on to the client.  The referral      
  7318.  
  7319.   "Extensions to the Internet Relay Chat Protocol (IRCX)", T. Pfenning, K. 
  7320.   Cedola, Lisa Dusseault, 08/21/1997, 
  7321.   <draft-pfenning-irc-extensions-02.txt>                                   
  7322.  
  7323.     This  document  describes  extensions to the Internet Relay Chat (IRC) 
  7324.     protocol defined in RFC 1459[1].  Only client-server interactions are  
  7325.     defined. The added functionality includes optional user authentication 
  7326.     for multiple security providers, support for UNICODE[2] characters,    
  7327.     multilayer security, and a unified property mechanism.  Chat server    
  7328.     implementations can optionally support channel or server services with 
  7329.     full control over all messages and events. These services communicate  
  7330.     with the core server over an extended IRC connection.
  7331.      
  7332.     All changes to the IRC protocol are designed in a way that existing   
  7333.     clients  will continue to work against servers implementing the exten- 
  7334.     sions. Support for the extended protocol can be queried by clients to  
  7335.     take advantage of the added functionality or to conform to the basic   
  7336.     protocol as defined in RFC1459.                                        
  7337.  
  7338.   "Extensions for Distributed Authoring and Versioning on the World Wide 
  7339.   Web -- WEBDAV", Jim Whitehead, D. Jensen, S. Carter, Y. Goland, A. Faizi,
  7340.   03/26/1997, <draft-jensen-webdav-ext-01.txt>                             
  7341.  
  7342.     WEBDAV (Web Distributed Authoring and Version control) specifies a set 
  7343.     of methods and content-types ancillary to HTTP/1.1 for the management 
  7344.     of resource meta-data, simple name space manipulation, simple resource 
  7345.     locking (collision avoidance) and resource version control.            
  7346.  
  7347.   "Electronic Part Catalog to Business System Interface", S. Sheppard, S. 
  7348.   Peoples, 02/10/1997, <draft-rfced-info-sheppard-00.txt>                  
  7349.  
  7350.     This Internet-Draft specifies a standard method of transferring part 
  7351.     and pick list information between dealer business systems (DBS) and  
  7352.     electronics parts catalog (EPC) systems.                               
  7353.  
  7354.   "Telnet Remote Serial Port (RSP) Option", R. Barnes, M. Bennett, 
  7355.   02/10/1997, <draft-rfced-info-bennett-00.txt>                            
  7356.  
  7357.     This document is a submission to the Internet Engineering Task Force 
  7358.     (IETF) as an Internet draft standard.                                  
  7359.  
  7360.   "Dublin Core Metadata for Simple Resource Description", J. Kunze, S. 
  7361.   Weibel, C. Lagoze, 09/03/1997, <draft-kunze-dc-01.txt>                   
  7362.  
  7363.     The Dublin Core Metadata Workshop Series began in 1995 with an
  7364.     invitational workshop intended to bring together librarians, digital
  7365.     library researchers, content experts, and text-markup experts to
  7366.     promote better discovery standards for electronic resources.  The
  7367.     Dublin Core is a 15-element set of descriptors that has emerged from
  7368.     this effort in interdisciplinary and international consensus building.
  7369.     This is the first of a set of documents describing the Dublin Core.    
  7370.  
  7371.   "An Extension to the Web Robots Control Method for supporting Mobile 
  7372.   Agents", F. Giudici, A. Sappia, 02/18/1997, 
  7373.   <draft-giudici-web-robots-cntrl-00.txt>                                  
  7374.  
  7375.     The Web Robots Control Standard [1] is a method for administrators of 
  7376.     sites on the World-Wide-Web to give instructions to visiting Web 
  7377.     robots. This document describes an extension for supporting Robots 
  7378.     based on Mobile Agents, in a way that is independent of the technology 
  7379.     used for their actual implementation.                                  
  7380.  
  7381.   "Clearing the Traffic Jam at Internet Servers  A Network Layer View Of 
  7382.   Network Traffic Consolidation", J. Mansigian, 03/03/1997, 
  7383.   <draft-mansigian-ntc-intro-01.txt>                                       
  7384.  
  7385.     The cause of the typically glacial response from popular Internet World
  7386.     Wide Web servers is seldom lack of network bandwidth or any deficits in
  7387.     the client's equipment. The reason for the abysmal performance is that 
  7388.     the accessed server is spending an inordinate amount of time managing 
  7389.     two problems; an unnecessarily large number of transport connections 
  7390.     and the transmission of masses of redundant data without optimization. 
  7391.     This work addresses both problems.                                     
  7392.     This document presents an introduction to the concepts and architecture
  7393.     of network traffic consolidation. It is not intended to describe a 
  7394.     complete protocol with every ancillary feature but rather to focus on 
  7395.     performance driven core ideas that could become a part of emerging 
  7396.     commercially featured protocols.                                       
  7397.  
  7398.   "BOOTP and DHCP on Mixed Media Link-Layer Networks", Walt Wimer, S. 
  7399.   Martel, 02/20/1997, <draft-martel-bootp-mixedlinklayers-00.txt>          
  7400.  
  7401.     RFCs 951 [1], 1541 [2], and 1542 [3] describe the interactions of BOOTP
  7402.     [1] and DHCP [2] client, server, and relay agents.  However, further 
  7403.     experience with these protocols has revealed the existence of an 
  7404.     interoperability issue.  The issue occurs when a given IP subnet is 
  7405.     constructed over one link-layer network inter-connected by 
  7406.     translational bridges to other dissimilar link-layer networks.  The 
  7407.     following information attempts to address this problem.   It is 
  7408.     impossible for a BOOTP or DHCP client, server, or relay agent to know 
  7409.     in advance whether or not it will be operating in a mixed media 
  7410.     link-layer network environment.  Given this fact, all BOOTP and DHCP 
  7411.     client, server, and relay agents SHOULD adopt the recommendations 
  7412.     defined in this memo.                                                  
  7413.  
  7414.   "Fine-Grained Transclusion in the Hypertext Markup Language", A. Pam, 
  7415.   02/25/1997, <draft-pam-html-fine-trans-00.txt>                           
  7416.  
  7417.     The word 'hypertext' was coined by Theodor Holm Nelson in his paper 'A 
  7418.     File Structure for the Complex, the Changing and the Indeterminate', 
  7419.     presented at the ACM 20th national conference in 1965.  One of the key 
  7420.     concepts in Nelson's vision of hypertext is 'transclusion' or virtual 
  7421.     inclusion, which permits composite documents to be constructed by 
  7422.     reference to the original components rather than by copying.           
  7423.     The Hypertext Markup Language (HTML) is a markup language used to 
  7424.     create hypertext documents that are platform independent.  HTML 
  7425.     currently permits the transclusion of various content types using tags 
  7426.     which accept a 'SRC' attribute, such as the IMG, EMBED and APPLET tags,
  7427.     but does not provide a mechanism for transcluding textual content.  
  7428.     This document proposes markup for text transclusions in HTML and 
  7429.     explains its usage.                                                    
  7430.  
  7431.   "UUIDs and GUIDs", P. Leach, R. Salz, 02/25/1997, 
  7432.   <draft-leach-uuids-guids-00.txt>                                         
  7433.  
  7434.     This specification defines the format of UUIDs (Universally Unique 
  7435.     IDentifier), also known as GUIDs (Globally Unique IDentifier). A UUID 
  7436.     is 128 bits long, and if generated according to the one of the 
  7437.     mechanisms in this document, is either guaranteed to be different from 
  7438.     all other UUIDs/GUIDs generated until 3400 A.D. or extremely likely to 
  7439.     be different (depending on the mechanism chosen). UUIDs were originally
  7440.     used in the Network Computing System (NCS) [1] and later in the Open 
  7441.     Software Foundation's (OSF) Distributed Computing Environment [2].     
  7442.     This specification is derived from the latter specification with the 
  7443.     kind permission of the OSF.                                            
  7444.  
  7445.   "GSE+ - An Alternate Addressing Architecture to GSE", A. Durand, 
  7446.   02/26/1997, <draft-durand-gse+-00.txt>                                   
  7447.  
  7448.     This document present an alternative addressing architecture to the GSE
  7449.     proposal (draft-ipng-gseaddr-00.txt) of Mike O'dell.  The basic change 
  7450.     is the introduction of a site identifier in the ESD.                   
  7451.  
  7452.   "E-mail addressing: the worst of all worlds?", G. Klyne, 02/26/1997, 
  7453.   <draft-klyne-addressing-00.txt>                                          
  7454.  
  7455.     This memo is a critique of Internet e-mail addressing, with particular 
  7456.     reference to its suitability for use in a general purpose interpersonal
  7457.     communication medium as opposed to its present use largely within a 
  7458.     restricted community.                                                  
  7459.     The critique focusses on the differences between e-mail addresses and 
  7460.     other forms of addressing with which very many lay people are 
  7461.     intimately familiar.                                                   
  7462.     This memo does not offer any solutions to the issues raised; rather it 
  7463.     is hoped to provoke some debate on the matter.  The author would be 
  7464.     particularly interested in views from those whose natural language does
  7465.     not use the Roman (western) alphabet.                                  
  7466.  
  7467.   "DHCP Option for Proxy Client Configuration File", S. Kwan, 02/26/1997, 
  7468.   <draft-kwan-proxy-client-conf-00.txt>                                    
  7469.  
  7470.     Application-level gateways are used on networks to provide controlled 
  7471.     access to the Internet.  Clients in those networks must be configured 
  7472.     with the name or address of available proxy servers, the list of local 
  7473.     domain names, and other proxy client configuration information before 
  7474.     they can access the Internet.  The defacto method of proxy client 
  7475.     configuration is the download of a script or configuration file named 
  7476.     by a URL.  This document describes a DHCP option in which to transmit 
  7477.     this URL to a proxy client.                                            
  7478.  
  7479.   "Distributed Search Management Protocol", J. Floyd, 03/03/1997, 
  7480.   <draft-floyd-distributed-search-01.txt>                                  
  7481.  
  7482.     There are a number of instances in which the search for a particular 
  7483.     value (for instance, a cryptographic key) can be distributed across a 
  7484.     large number of machines, however there is not currently a standard 
  7485.     protocol for doing so.  A great many algorithms may be used for 
  7486.     searches; because these algorithms may differ greatly, the protocol 
  7487.     used must be flexible enough to be easily extended.                    
  7488.  
  7489.   "Zone KEY RRSet Signing Procedure", O. Gudmundsson, E. Lewis, 03/25/1997,
  7490.   <draft-lewis-dnskey-handling-01.txt>                                     
  7491.  
  7492.     Under the security extensions to DNS, as defined in RFC 2065 and 
  7493.     draft-ietf-dnssec-update-04.txt, a secured zone will have a KEY RRSet 
  7494.     associated with the domain name at the apex of the zone. This document 
  7495.     covers the manner in which this RRSet is generated, signed, and 
  7496.     inserted into the name servers.                                        
  7497.  
  7498.   "Extended Path MTU Discovery for IP version 6", D. Sanghi, S. Shah, 
  7499.   03/04/1997, <draft-sanghi-pmtudisc-ext-00.txt>                           
  7500.  
  7501.     This draft discusses extensions to the present Path MTU Discovery 
  7502.     mechanism [PMTUDISC]. It provides applications finer control over the 
  7503.     delay and losses incurred during the PMTU Discovery process. The 
  7504.     document proposes two extension header options that allow PMTU 
  7505.     Discovery with minimal overheads.                                      
  7506.  
  7507.   "Usage of H.323 on the Internet", P. Lantz, 03/04/1997, 
  7508.   <draft-rfced-info-lantz-00.txt>                                          
  7509.  
  7510.     The H.323 standard defined by the International Telecommunication Union
  7511.     (ITU) describes 'Visual telephone systems and equipment for local area 
  7512.     networks which provide a non-guaranteed quality of service', that is to
  7513.     say, video conferencing over Local Area Networks and the Internet.     
  7514.     Although it has been generally accepted that H.323 is an appropriate 
  7515.     standard for audio/video telephony on the Internet, it is a complex 
  7516.     standard. It describes a broad and complex set of capabilities, 
  7517.     including interoperation with other types of video conferencing 
  7518.     systems, and contains references to a number of other ITU standards.   
  7519.     This document describes the parts of the standard that are necessary 
  7520.     for Internet telephony and multipoint conferencing. It describes the 
  7521.     messages that are necessary to work with other H.323 implementations. 
  7522.     In a separate section, it also lists the messages that must be 
  7523.     implemented to be H.323 compliant.  This document is a guide to make 
  7524.     the standard more accessible. It is not intended to duplicate 
  7525.     information in the standard. It does not contain specifications of the 
  7526.     messages or details of the protocol.                                   
  7527.  
  7528.   "Practical Approach to Improving Scalability and Interoperability of SNMP
  7529.   Applications", A. Romanov, 03/04/1997, <draft-rfced-info-romanov-00.txt> 
  7530.  
  7531.     The goal of this memo is to provide a simple solution for apparent 
  7532.     practical problem of scalability and interoperability of network 
  7533.     management applications.                                               
  7534.  
  7535.   "Definitions of Managed Objects for IEEE 802.1q Virtual LAN Bridges", I. 
  7536.   Jeyasubramanian, 06/12/1997, <draft-jeya-vlan-8021q-mib-01.txt>          
  7537.  
  7538.     This memo defines a portion of the Management Information Base (MIB) 
  7539.     for use with network management protocols in the Internet community.  
  7540.     In particular it describes objects used for managing bridges based on 
  7541.     the IEEE 802.1q draft standard between Local Area Network (LAN) 
  7542.     segments.      This memo uses SNMPv2 as the basis for defining VLAN 
  7543.     MIB, and refers to other MIBs whose published definitions use SNMPv2 
  7544.     convention                                                             
  7545.  
  7546.   "A Proposal for Internet and Public Switched Telephone Networks (PSTN) 
  7547.   Internetworking", Igor Faynberg, H. Lu, M. Krishnaswamy, 03/05/1997, 
  7548.   <draft-faynberg-telephone-sw-net-00.txt>                                 
  7549.  
  7550.     The purpose of this Internet Draft is to start discussion on the issues
  7551.     involved in interconnecting Internet and Public Switched Networks so as
  7552.     to provide more effective media than either network type can do 
  7553.     presently. Interworking of the Internet and PSTNs, based on open 
  7554.     well-defined interfaces, will promote interoperability of both the 
  7555.     networks and systems built by different vendors.                       
  7556.  
  7557.   "Semantics of DNS NXT Resource Records", O. Gudmundsson, E. Lewis, 
  7558.   03/25/1997, <draft-lewis-dnsnxt-semantics-01.txt>                        
  7559.  
  7560.     In 'Domain Name System Security Extensions' (RFC 2065) the NXT Resource
  7561.     Record (along with SIG RR and KEY RR) is introduced to allow for secure
  7562.     denial of existence of either a domain name or a RRSet belonging to an 
  7563.     existing domain name.  The set of NXT records within a zone create a 
  7564.     virtual 'chain' of RRSets within a zone by indicating, for each name 
  7565.     within a zone, the RRSets for which it owns records and the next name 
  7566.     in the zone.                                                           
  7567.     RFC 2065 discusses security extensions for static DNS zones.  An 
  7568.     Internet Draft, draft-ietf-dnssec-update-04.txt, becoming an RFC 
  7569.     describes security in DNS zone which can be dynamically updated.  In 
  7570.     this document, the authors build upon them to:  - define some terms 
  7571.     used colloquially in the working group - describe the semantics of the 
  7572.     NXT record in greater detail than the two existing documents, in order 
  7573.     to achieve interoperability  - introduce and discuss unresolved issues 
  7574.     involving NXT records                                                  
  7575.  
  7576.   "VIPRE -- Virtual Internet Packet Relay: An Encapsulation Architecture 
  7577.   for Unidirectional Links", J. Stepanek, S. Schwab, 03/06/1997, 
  7578.   <draft-stepanek-vipre-00.txt>                                            
  7579.  
  7580.     This memo describes a method of incorporating unidirectional links into
  7581.     an IP network in a bidirectional mode by relaying encapsulated IP 
  7582.     packets over a bidirectional network.                                  
  7583.  
  7584.   "Point-to-point Link Assembly for Simple Multiple Access (PLASMA)", K. 
  7585.   Fujikawa, 03/12/1997, <draft-fujikawa-plasma-00.txt>                     
  7586.  
  7587.     This document describes PLASMA, which enables a simple multicast 
  7588.     mechanism and autoconfiguration in an IP subnet consisting of 
  7589.     point-to-point links, such as ATM, Frame Relay, SONET/SDH, etc.  PLASMA
  7590.     utilizes an L2 label switching mechanism and creates data flow paths in
  7591.     a subnet using the PLASMA protocol.  The PLASMA protocol is very simply
  7592.     defined and works effectively within a single IP subnet.  PLASMA 
  7593.     applications to ATM and PPP are also described.                        
  7594.  
  7595.   "Update of Korean Character Encoding for Internet Messages", S. Chi, J. 
  7596.   Kim, S. Choi, I. Choi, S. Park, 03/14/1997, <draft-rfced-info-kim-00.txt>
  7597.  
  7598.     Since RFC 1557, which is a Korean character encoding for internet 
  7599.     messages, was distributed in 1993, most mailers have been implemented 
  7600.     using it. However, it's been reported many occurrences of incompatible 
  7601.     transfer of Korean mail messages such as broken mail messages. 
  7602.     Therefore certain features are need to be extended, and ambiguous 
  7603.     contents must be clarified. This document updates RFC 1557 to resolve 
  7604.     above matters.        This memo provides information for the Internet 
  7605.     community. This memo does not specify an Internet standard of any kind.
  7606.     Distribution of this memo is unlimited.                                
  7607.  
  7608.   "Scalable support for multi-homed multi-provider connectivity", Y 
  7609.   Rekhter, T. Bates, 07/09/1997, <draft-bates-multihoming-01.txt>          
  7610.  
  7611.     This document describes addressing and routing strategies for 
  7612.     multi-homed enterprises attached to multiple Internet Service Providers
  7613.     (ISPs) that are intended to reduce the routing overhead due to these 
  7614.     enterprises in the global Internet routing system.                     
  7615.  
  7616.   "Reliable Multicast Transport Protocol", N. Yamanouchi, T. Shiroshita, T.
  7617.   Sano, O. Takahashi, 09/03/1997, <draft-shiroshita-rmtp-spec-01.txt>      
  7618.  
  7619.     This draft presents the specifications of the 'Reliable Multicast
  7620.     Transport Protocol,' which is used for information delivery such as
  7621.     newspaper delivery and software updates. The protocol aims to realize
  7622.     a full reliable multicast of bulk data from a server to thousands of
  7623.     receivers.  Scalability of the protocol, flow/congestion control
  7624.     extension, and security issues are described as an addendum for the
  7625.     protocol specifications. This document defines RMTP version 1
  7626.     specification and also constitutes a Part 1 of RMTP version 2
  7627.     specification.                                                         
  7628.  
  7629.   "Returning Values from Forms:  multipart/form-data", Larry Masinter, 
  7630.   08/02/1997, <draft-masinter-form-data-01.txt>                            
  7631.  
  7632.     This specification defines an Internet Media Type,
  7633.        multipart/form-data, which can be used by a wide variety of
  7634.        applications and transported by a wide variety of protocols as a
  7635.        way of returning a set of values as the result of a user filling
  7636.        out a form.                                                         
  7637.  
  7638.   "Wildcards in the Accept-Charset Header", K. Holtman, 03/20/1997, 
  7639.   <draft-holtman-http-wildcards-00.txt>                                    
  7640.  
  7641.     The HTTP/1.1 specification (RFC 2068) defines an Accept-Charset header,
  7642.     but fails to define a wildcard '*' which could be used in this header 
  7643.     to match all character sets.  This proposal corrects this omission.    
  7644.  
  7645.   "DIAMETER Authentication Extensions", Allan Rubens, Pat Calhoun, 
  7646.   03/21/1997, <draft-calhoun-diameter-authent-00.txt>                      
  7647.  
  7648.     DIAMETER is a management protocol used between Network Access Servers 
  7649.     and DIAMETER Servers for authentication, authorization, accounting of 
  7650.     dial-up users. A considerable amount of effort was put into the design 
  7651.     of this protocol to ensure that an implementation could support both 
  7652.     DIAMETER and RADIUS at the same time.                                  
  7653.     This document details the RADIUS authentication messages and how they 
  7654.     may be used with the DIAMETER protocol.                                
  7655.  
  7656.   "QoS Path Management with RSVP", R. Guerin, Shai Herzog, S. Kamat, 
  7657.   03/21/1997, <draft-guerin-qospath-mgmt-rsvp-00.txt>                      
  7658.  
  7659.     This document describes a proposal aimed at allowing management through
  7660.     the RSVP [RZB+96] protocol of paths selected by a QoS routing algorithm
  7661.     such as those of [GOW96, ZSSC96].  The goals of the proposal are to 
  7662.     allow efficient management of such QoS paths with the minimum possible 
  7663.     impact to the RSVP protocol and the existing routing infrastructure.  
  7664.     Basic features of the approach include leveraging of RSVP soft state 
  7665.     mechanisms, and simple extensions to enable soft pinning (sticking) of 
  7666.     paths selected by the QoS routing algorithm.  In addition, the proposal
  7667.     addresses the issue of preventing the formation of data path loops, and
  7668.     of avoiding potential race conditions.                                 
  7669.  
  7670.   "DIAMETER", Allan Rubens, Pat Calhoun, 03/21/1997, 
  7671.   <draft-calhoun-diameter-00.txt>                                          
  7672.  
  7673.     This original document was named Enhanced RADIUS and was changed at the
  7674.     request of the WG since this protocol is different from the former.    
  7675.     This document describes a management protocol used between Network 
  7676.     Access Servers and DIAMETER Servers for authentication, authorization, 
  7677.     accounting of dial-up users. A considerable amount of effort was put 
  7678.     into the design of this protocol to ensure that an implementation could
  7679.     support both DIAMETER and RADIUS at the same time.                     
  7680.  
  7681.   "DIAMETER Extensible Authentication Protocol Support", Allan Rubens, B. 
  7682.   Aboba, Pat Calhoun, 03/21/1997, <draft-calhoun-diameter-eap-00.txt>      
  7683.  
  7684.     The Extensible Authentication Protocol (EAP) is a PPP extension that 
  7685.     provides support for additional authentication methods within PPP.   
  7686.     This document describes how the EAP Protocl may be used in conjunction 
  7687.     with the DIAMETER protocol.                                            
  7688.  
  7689.   "IMAP4 ID extension", T. Showalter, 03/21/1997, 
  7690.   <draft-showalter-imap-id-00.txt>                                         
  7691.  
  7692.     The purpose of the ID extension to the IMAP4rev1 protocol is to allow 
  7693.     the server and client to exchange identification information on their 
  7694.     implementation in order to make bug reports and usage statistics more 
  7695.     complete.                                                              
  7696.     Although the IMAP4rev1 protocol described in [IMAP4rev1] provides a 
  7697.     method for accessing remote mail stores, there is no facility to 
  7698.     advertise what program a client or server uses to provide service. This
  7699.     makes it difficult for implementors to get complete bug reports from 
  7700.     users, as it is frequently difficult to know what client or server is 
  7701.     in use.           Additionally, some sites may wish to assemble usage 
  7702.     statistics based on what clients are used, but in an an environment 
  7703.     where users are permitted to obtain and maintain their own clients this
  7704.     is difficult to accomplish.                                            
  7705.  
  7706.   "Internet Public Key Infrastructure:  Web-based Certificate and CRL 
  7707.   Repository", Y. Sameshima, H. Kikuchi, M. Sakurai, H. Hattori, 
  7708.   03/24/1997, <draft-kikuchi-web-cert-repository-00.txt>                   
  7709.  
  7710.     This document provides a specification how to publish and retrieve 
  7711.     X.509 certificates and certificate revocation lists (CRLs).  In the 
  7712.     proposed method, the World Wide Web (WWW) is used for securely 
  7713.     distributing certificates across a firewall in both human and machine 
  7714.     readable syntax. A various certificate concerning information that 
  7715.     includes certificates, CRLs, and certification authority (CA) policy 
  7716.     are retrieved from an integrated single authority access point 
  7717.     specified in X.509 version 3 extensions. The information access point 
  7718.     accepts certification and revocation requests in the uniform access 
  7719.     method based on the standard WWW.                                      
  7720.  
  7721.   "SMTP Service Extension for Secure SMTP over TLS", Paul Hoffman, 
  7722.   06/02/1997, <draft-hoffman-smtp-ssl-03.txt>                              
  7723.  
  7724.     This document describes an extension to the SMTP service that allows an
  7725.     SMTP server and client to use transport-layer security to provide 
  7726.     private, authenticated communication over the Internet. This gives SMTP
  7727.     agents the ability to protect some or all of their communications from 
  7728.     eavesdroppers and attackers.                                           
  7729.  
  7730.   "Simple Integrated Media Access (SIMA)", K. Kilkki, 06/18/1997, 
  7731.   <draft-kalevi-simple-media-access-01.txt>                                
  7732.  
  7733.     The basic objectives of future Internet are to increase the network 
  7734.     capacity, to offer a practical real-time service, and to develop a 
  7735.     feasible charging scheme. These objectives introduce very strict 
  7736.     requirements for the traffic control system. This paper presents a new 
  7737.     simple approach for traffic management: Simple Integrated Media Access 
  7738.     (SIMA) service. According to the SIMA concept each customer shall 
  7739.     define only two issues before a connection establishment: a nominal bit
  7740.     rate (NBR) and the selection between real-time and non-real-time 
  7741.     service classes. NBR has two purposes: it forms the basis of charging, 
  7742.     and it defines how the network capacity is divided among different 
  7743.     connections during overload situations. Simplicity means that, on the 
  7744.     one hand, the network operator does not guarantee the continuous 
  7745.     availability of network operator does not guarantee the continuous 
  7746.     availability of nominal bit rate, and on the other hand, the user is 
  7747.     allowed to send data with any bit rate independently of the NBR. 
  7748.     However, the bit rate of transmission defines the cell loss probability
  7749.     in the case of network congestion. In this way a simple, but effective,
  7750.     self-regulation of traffic can be                                      
  7751.  
  7752.   "Realizing the Benefits of Virtual LANs by Using IPv6", J. Le Boudec, T. 
  7753.   Kurz, H. Einsiedler, 03/25/1997, 
  7754.   <draft-kurz-virtual-lans-benefits-00.txt>                                
  7755.  
  7756.     The benefits that Virtual LANs offer can be realized by using features 
  7757.     of an IPv6 network along with small enhancements the IPv6 and DHCPv6 
  7758.     protocol stacks.                                                       
  7759.  
  7760.   "Host Reachability Advertisement for IPv6", J. McCann, 03/25/1997, 
  7761.   <draft-mccann-ipv6-hra-00.txt>                                           
  7762.  
  7763.     This document describes a mechanism that can be used by IPv6 hosts to 
  7764.     communicate information about their address configuration to 
  7765.     neighboring routers.  In particular, this mechanism is intended to 
  7766.     allow multihomed hosts and hosts with anycast addresses to communicate 
  7767.     this information to their neighboring routers.  This document defines a
  7768.     new ICMPv6 informational message type, a 'Host Reachability 
  7769.     Advertisement' to carry this information.  It also defines a second 
  7770.     ICMPv6 message, a 'Host Reachability Solicitation', that can be used to
  7771.     trigger Host Reachability Advertisements.                              
  7772.  
  7773.   "Header Compression for IPv6 over PPP", M. Engan, 03/25/1997, 
  7774.   <draft-engan-ipv6-hc-00.txt>                                             
  7775.  
  7776.     The Point-to-Point Protocol [RFC1548] provides a standard method of 
  7777.     encapsulating Network Layer protocol information over point-to-point 
  7778.     links.                                                                 
  7779.     Header Compression for IPv6 [IPv6HC] is a method to compress IPv6 
  7780.     datagram headers (any combination of IPv6, IPv4, TCP and UDP headers 
  7781.     can be compressed).                                                    
  7782.     This document describes methods for transmission of datagrams with 
  7783.     headers compressed by IPv6 Header Compression over point-to-point 
  7784.     links.                                                                 
  7785.  
  7786.   "The Use of URLs as Meta-Syntax for Core Mail List Commands and their 
  7787.   Transport through Message Header Fields", J. Baer, G. Neufeld, 
  7788.   08/21/1997, <draft-baer-listspec-01.txt>                                 
  7789.  
  7790.        The mailing list command specification header fields are a simple 
  7791.     set
  7792.        of fields to be added to email messages sent by email distribution
  7793.        lists. Each field contains a URL (usually mailto) locating the
  7794.        relevant information or performing the command directly.  The three
  7795.        core header fields described in this document are List-Help,
  7796.        List-Subscribe, and List-Unsubscribe.
  7797.      
  7798.        There are three other header fields described here which, although
  7799.        not as widely applicable, will have utility for a sufficient number
  7800.        of mailing lists to justify their formalization here. These are
  7801.        List-Post, List-Owner and List-Archive.
  7802.      
  7803.        By including these header fields, mail clients can provide automated
  7804.        tools for performing these functions.  This could take the form of a
  7805.        menu item, push button, or other user interface element.  The intent
  7806.        is to simplify the user experience, providing a common interface to
  7807.        the often cryptic and varied mailing list manager commands.         
  7808.  
  7809.   "S/MIME Message Specification", S. Dusse, L. Lundblade, Paul Hoffman, L. 
  7810.   Repka, B. Ramsdell, 10/21/1997, <draft-dusse-smime-msg-05.txt>           
  7811.  
  7812.     S/MIME (Secure/Multipurpose Internet Mail Extensions) provides a
  7813.     consistent way to send and receive secure MIME data. Based on the
  7814.     popular Internet MIME standard, S/MIME provides the following
  7815.     cryptographic security services for electronic messaging applications:
  7816.     authentication, message integrity and non-repudiation of origin (using
  7817.     digital signatures) and privacy and data security (using encryption).  
  7818.  
  7819.   "S/MIME Certificate Handling", S. Dusse, Paul Hoffman, Jeff Weinstein, B.
  7820.   Ramsdell, 10/21/1997, <draft-dusse-smime-cert-04.txt>                    
  7821.  
  7822.     S/MIME (Secure/Multipurpose Internet Mail Extensions), described in
  7823.     [SMIME-MSG], provides a method to send and receive secure MIME
  7824.     messages. In order to validate the keys of a message sent to it, an
  7825.     S/MIME agent needs to certify that the key is valid. This draft
  7826.     describes the mechanisms S/MIME uses to create and validate keys using
  7827.     certificates.                                                          
  7828.  
  7829.   "Recommendations on Queue Management and Congestion Avoidance in the 
  7830.   Internet", Jon Crowcroft, 03/25/1997, <draft-irtf-e2e-queue-mgt-00.txt, 
  7831.   .ps>                                                                     
  7832.  
  7833.     This memo presents two recommendations to the Internet community 
  7834.     concerning measures to improve and preserve Internet performance.  It 
  7835.     presents a strong recommendation for testing, standardization, and 
  7836.     widespread deployment of active queue management in routers, to improve
  7837.     the performance of today's Internet.  It also urges a concerted effort 
  7838.     of research, measurement, and ultimate deployment of router mechanisms 
  7839.     to protect the Internet from flows that are not sufficiently responsive
  7840.     to congestion notification.                                            
  7841.  
  7842.   "RSVP over ATM Implementation Guidelines", Lou Berger, 07/11/1997, 
  7843.   <draft-ietf-issll-atm-imp-guide-01.txt, .ps>                             
  7844.  
  7845.     This note presents specific implementation guidelines for running RSVP 
  7846.     over ATM switched virtual circuits (SVCs).  The general problem is 
  7847.     discussed in [8].  Implementation requirements are discussed in [3].  
  7848.     Integrated Services to ATM service mappings are covered in [6]. The 
  7849.     full set of documents present the background and information needed to 
  7850.     implement Integrated Services and RSVP over ATM.                       
  7851.  
  7852.   "HTTP 1.1 as a Transport for the Internet Printing Protocol", R. Turner, 
  7853.   03/25/1997, <draft-turner-ipp-trans-develop-00.txt>                      
  7854.  
  7855.     The definition of the Internet Printing Protocol (IPP) is specified 
  7856.     abstractly, and does not detail a particular implementation. The 
  7857.     abstract definition of IPP is contained within the 'IPP Model' 
  7858.     document, a separate document available at the Printer Working Group 
  7859.     IPP web page HTTP://www.pwg.org/. This document attempts to map IPP 
  7860.     Model operations and semantics to HTTP 1.1 equivalent operations.      
  7861.  
  7862.   "QoS Routing Mechanismsand OSPFExtensions", R. Guerin, D. Williams, T. 
  7863.   Przygienda, S. Kamat, A. Orda, 03/26/1997, 
  7864.   <draft-guerin-qos-routing-ospf-01.txt>                                   
  7865.  
  7866.     This memo describes extensions to the OSPF [Moy94] protocol to support 
  7867.     QoS routes.  The focus of the document is on the algorithms used to 
  7868.     compute QoS routes and on the necessary modifications to OSPF to 
  7869.     support this function, e.g., the information needed, its format, how it
  7870.     is distributed, and how it is used by the QoS path selection process.  
  7871.     Aspects related to how QoS routes are established and managed are also 
  7872.     discussed.  The goal of this document is to identify a framework and 
  7873.     possible approaches to allow deployment of QoS routing capabilities 
  7874.     with the minimum possible impact to the existing routing 
  7875.     infrastructure.                                                        
  7876.  
  7877.   "RIDE classes", Rick Wesson, David Kessens, D. Shah, 09/10/1997, 
  7878.   <draft-kessens-ride-classes-01.txt>                                      
  7879.  
  7880.        This document describes the attributes and classes that will be used
  7881.        in the internet Registry Information Database Exchange formats
  7882.        (RIDE). For now it is mostly limited to 'domain' and 'contact'
  7883.        classes since they were widely considered as most urgent. Encoding
  7884.        that will be used for the objects and ways to find and access 
  7885.     objects
  7886.        are beyond the scope of this document. This will be addressed in the
  7887.        future in separate drafts.                                          
  7888.  
  7889.   "Internet Printing Protocol/1.0: Security", R. deBry, J. Hadsell, D. 
  7890.   Manchala, X. Riley, J. Wenn, 03/26/1997, <draft-debry-ipp-sec-00.txt>    
  7891.  
  7892.     This document is one of a set of documents which together describe all 
  7893.     aspects of a new Internet Printing Protocol (IPP). IPP is an 
  7894.     application level protocol that can be used for distributed printing on
  7895.     the Internet. The protocol is heavily influenced by the printing model 
  7896.     introduced in the Document Printing Application (ISO/IEC 10175 DPA) 
  7897.     standard, which describes a distributed printing service.              
  7898.  
  7899.   "Physical Topology MIB and Discovery Protocol Proposal", Keith 
  7900.   McCloghrie, Andy Bierman, 03/26/1997, 
  7901.   <draft-bierman-ptopo-mib-proto-00.txt>                                   
  7902.  
  7903.     This memo defines an experimental portion of the Management Information
  7904.     Base (MIB) for use with network management protocols in the Internet 
  7905.     Base (MIB) for use with network management protocols in the Internet 
  7906.     managing physical topology identification and discovery.               
  7907.  
  7908.   "Multicast Chat (MCC) Protocol", K. Hay, 03/26/1997, 
  7909.   <draft-hay-mcc-00.txt>                                                   
  7910.  
  7911.     This document is an rough draft for a proposed new Internet 
  7912.     conferencing protocol called multicast chat (MCC) which uses IP 
  7913.     multicast for the internet layer.                                      
  7914.  
  7915.   "CIFS Logon and Pass Through Authentication Preliminary Draft", P. Leach,
  7916.   D. Naik, 03/26/1997, <draft-leach-cifs-logon-spec-00.txt>                
  7917.  
  7918.     This specification defines how a certain Common Internet File Systems 
  7919.     (CIFS) client accomplishes logging on to a CIFS server. The 
  7920.     specification also details how a CIFS server may accomplish pass 
  7921.     through authentication.                                                
  7922.  
  7923.   "Physical Topology Terminology", Y. Malachi, 03/26/1997, 
  7924.   <draft-malachi-topology-terms-00.txt>                                    
  7925.  
  7926.     This draft proposes a common nomenclature for use by the Physical 
  7927.     Topology MIB Working Group. This glossary is based on the terms used in
  7928.     the various Internet Drafts submitted to this working group as well as 
  7929.     on some RFCs.  As we move forward with the definition of a common 
  7930.     topology MIB this glossary will evolve to reflect the new constructs in
  7931.     the MIB and this draft will probably become a section in the Physical 
  7932.     Topology MIB Internet Draft.   Although a topology MIB will include 
  7933.     many terms we include here only terms which are not well-defined 
  7934.     elsewhere or might be confusing here.                                  
  7935.  
  7936.   "Age Header Field in HTTP/1.1", R. Fielding, 09/16/1997, 
  7937.   <draft-fielding-http-age-00.txt>                                         
  7938.  
  7939.     The 'Age' response-header field in HTTP/1.1 [RFC 2068] is intended to 
  7940.     provide a lower-bound for the estimation of a response message's age 
  7941.     (time since generation) by explicitly indicating the amount of time 
  7942.     that is known to have passed since the response message was retrieved 
  7943.     or revalidated.  However, there has been considerable controversy over 
  7944.     when the Age header field should be added to a response.  This document
  7945.     explains the issues and provides a set of proposed changes for the 
  7946.     revision of RFC 2068.                                                  
  7947.  
  7948.   "Using TTLs with Administratively Scoped IP Multicast Addresses", Ross 
  7949.   Finlayson, 03/26/1997, <draft-finlayson-ttl-admin-scope-00.txt>          
  7950.  
  7951.     The use of 'administratively scoped' multicast address ranges (as 
  7952.     described in [1]) leads to a multicast traffic scoping mechanism that 
  7953.     is superior to the original 'TTL scoping' mechanism.                   
  7954.     Contrary to popular opinion, however, administrative (often abbreviated
  7955.     as 'admin') scoping does not truly *replace* TTL scoping.  In 
  7956.     particular, multicast-based applications must still be aware of which 
  7957.     TTL value(s) they use.                                                 
  7958.     In this document, we note that each definition of a range of admin 
  7959.     scoped multicast addresses should be accompanied by a corresponding 
  7960.     'maximum effective TTL' that should be used with these addresses.  We 
  7961.     describe how these TTL values are used by applications, and how they 
  7962.     may influence the configuration of multicast border routers.           
  7963.  
  7964.   "Requirements for Unreliable Multicasting of Web Resources", B. Aboba, 
  7965.   03/26/1997, <draft-aboba-unweb-00.txt>                                   
  7966.  
  7967.     This document discusses applications for unreliable multicasting of Web
  7968.     resources as well as requirements for an unreliable multicast protocol 
  7969.     suitable for this use.                                                 
  7970.  
  7971.   "The Receiver-Initiated Shortcut Path Protocol (RISP)", Y. Chen, J. 
  7972.   Ogawa, 08/28/1997, <draft-ogawa-receiver-shortcut-path-00.txt>           
  7973.  
  7974.          This memo defines the Receiver Initiated Shortcut Path (RISP)
  7975.          protocol for NBMA networks.  The protocol extends the NHRP message
  7976.          set by adding Callback Request and Reply messages to allow the
  7977.          destination host (or its corresponding egress router) to establish
  7978.          a shortcut path for a data flow, using the existing NBMA signaling
  7979.          protocols.  Because of this receiver-initiated mechanism, a
  7980.          shortcut-capable network can use just the NBMA ARP servers, such 
  7981.     as
  7982.          the ATMARP servers, instead of the more complex Next Hop
  7983.          Servers. This draft also describes how to extend NHRP with the 
  7984.     new,
  7985.          receiver-initiated mechanism.                                     
  7986.  
  7987.   "A Stream Cipher Encryption Algorithm", Rodney Thayer, 04/16/1997, 
  7988.   <draft-thayer-cipher-01.txt>                                             
  7989.  
  7990.     There is a need in the Internet community for an encryption algorithm 
  7991.     that provides interoperable operation with existing deployed commercial
  7992.     cryptographic applications.  This interoperability will allow for a 
  7993.     smoother transition to protocols that have been developed through the 
  7994.     IETF standards process.  This document describes an existing algorithm 
  7995.     that satisifies this requirement.                                      
  7996.  
  7997.   "Implications of the GSE Addressing Scheme to IPv6 Multicast", F. Dupont,
  7998.   03/26/1997, <draft-dupont-ipv6-gse-multicast-00.txt>                     
  7999.  
  8000.     This document presents some implications for the GSE Addressing Scheme 
  8001.     ([1] draft-ietf-ipngwg-gseaddr-00.txt proposal by Mike O'Dell) on IPv6 
  8002.     multicast: a new scope for large structures and a clever way to compare
  8003.     two addresses for the election of a designated router.                 
  8004.  
  8005.   "CIFS Remote Administration Protocol                                    
  8006.   Preliminary Draft", P. Leach, D. Naik, 03/26/1997, 
  8007.   <draft-leach-cifs-rap-spec-00.txt>                                       
  8008.  
  8009.     This specification defines how an RPC like mechanism may be implemented
  8010.     using the Common Internet File System (CIFS) Transact SMB. Specific 
  8011.     examples are provided of how a CIFS client may request a CIFS server to
  8012.     execute a function. The examples show complete details of the request 
  8013.     sent by the CIFS client and the response from the CIFS server.         
  8014.  
  8015.   "Locating DS Entries by E-mail Address                                  
  8016.   Preliminary Draft", P. Leach, 03/26/1997, 
  8017.   <draft-leach-asid-ds-email-00.txt>                                       
  8018.  
  8019.     The LDAPv3 protocol (as specified in [1]) is designed to be a 
  8020.     lightweight access protocol for directory services supporting X.500 
  8021.     models. In addition, in an Internet context, many of the names about 
  8022.     which users seek information are Internet email addresses. A native 
  8023.     LDAP based directory service for the Internet should make it convenient
  8024.     to process such names -- there is a huge social investment spanning two
  8025.     decades to get to the point where names like 'john.doe@somewhere.com' 
  8026.     can appear in newspaper articles, TV commercials, and on billboards and
  8027.     millions of people understand what do with them.                       
  8028.     This draft defines a very simple convention for  looking up information
  8029.     associated with people identified by Internet email addresses - really 
  8030.     nothing more than identifying an existing capability of LDAP, in the 
  8031.     hopes that the convention can become widespread.                       
  8032.  
  8033.   "CIFS Printing Specification   Preliminary Draft", P. Leach, D. Naik, 
  8034.   03/26/1997, <draft-leach-cifs-print-spec-00.txt>                         
  8035.  
  8036.     This specification defines how clients may submit print requests to a 
  8037.     server using SMBs . The specification also details how clients may 
  8038.     administer printing of the print requests they create, using SMBs 
  8039.     defined  in the Common Internet File System specification.             
  8040.  
  8041.   "ARIS: Aggregate Route-Based IP Switching", R. Woundy, R. Boivie, N. 
  8042.   Feldman, A. Viswanathan, 03/26/1997, 
  8043.   <draft-viswanathan-aris-overview-00.txt>                                 
  8044.  
  8045.     IP based networks use a number of routing protocols, including RIP, 
  8046.     OSPF, IS-IS, and BGP, to determine how packets ought to be routed.  
  8047.     Among these protocols, OSPF and BGP are IETF-recommended standards that
  8048.     have been extensively deployed and exercised in many networks.  In this
  8049.     memo, we describe a mechanism which uses these protocols as the basis 
  8050.     for switching IP datagrams, by the addition of a simple protocol 
  8051.     ('ARIS') that establishes switched paths through a network.  The ARIS 
  8052.     protocol allows us to leverage the advantages of switching technologies
  8053.     in an internet network.                                                
  8054.  
  8055.   "ARIS Specification", N. Feldman, A. Viswanathan, 03/26/1997, 
  8056.   <draft-feldman-aris-spec-00.txt>                                         
  8057.  
  8058.     ARIS (Aggregate Route-Based IP Switching) adds the advantages of 
  8059.     high-speed switching to a network based on routing protocols.  It 
  8060.     provides a means of mapping network-layer routing information to 
  8061.     link-layer switched paths, enabling datagrams to traverse a network at 
  8062.     media speeds.  This memo defines the ARIS protocol and its mechanisms. 
  8063.  
  8064.   "CIFS/E Browser Protocol                                                
  8065.   Preliminary Draft", P. Leach, D. Naik, 03/27/1997, 
  8066.   <draft-leach-cifs-browser-spec-00.txt>                                   
  8067.  
  8068.     The CIFS/E (CIFS extensions for enterprise networks) family of 
  8069.     protocols includes a protocol for browsing. Browsing is a mechanism for
  8070.     discovering servers that are running particular services (not just CIFS
  8071.     file services). Servers are organized into named groups called domains,
  8072.     which form browsing scopes. This document specifies version 1.15 of  
  8073.     the browsing protocol. It also specifies the mailslot protocol, because
  8074.     the browsing protocol depends on it (and  is the only CIFS/E protocol 
  8075.     which does).                                                           
  8076.  
  8077.   "Soft State Switching                                                   A
  8078.   Proposal to Extend RSVP for Switching RSVP Flows", A. Viswanathan, Vijay 
  8079.   Srinivasan, 03/27/1997, <draft-viswanathan-aris-rsvp-00.txt>             
  8080.  
  8081.     This memo describes a mechanism for establishing a switched path with 
  8082.     guaranteed Quality of Service for RSVP [1] flows in an integrated 
  8083.     switch-router environment.  It proposes an extension to the RSVP 
  8084.     protocol that allows establishment of a sequence of virtual connections
  8085.     along the hop-by-hop routed path by enabling adjacent nodes to exchange
  8086.     Layer-2 labels.  The labels correspond to information that identifies 
  8087.     the virtual connections; for example, the VPI/VCI value in the case of 
  8088.     an ATM-based Layer-2 infrastructure.                                   
  8089.  
  8090.   "Directory Entries From Email Address", B. Greenblatt, 07/23/1997, 
  8091.   <draft-greenblatt-defema-02.txt>                                         
  8092.  
  8093.     This draft describes various means for finding a user's directory entry
  8094.     in a LDAP directory presuming that the user's electronic mail address 
  8095.     is known. This draft does not presume any specific DIT structure or 
  8096.     schema modifications.                                                  
  8097.  
  8098.   "Simple Transaction Security (STS)", B. Tung, 08/01/1997, 
  8099.   <draft-tung-transsec-sts-01.txt>                                         
  8100.  
  8101.         This document describes Simple Transaction Security (STS), a
  8102.         protocol for specifying services and protocols used to secure an
  8103.         enclosed message.  The framework is flexible enough to allow a wide
  8104.         variety of protocols to be used, at the cost of some negotiation 
  8105.     and
  8106.         the optimizations present in protocols such as S-HTTP.
  8107.                                                                            
  8108.  
  8109.   "Compression in IP Security", Rodney Thayer, R. Monsour, M. Sabin, A. 
  8110.   Shacham, S. Anand, 03/27/1997, <draft-monsour-compr-ipsec-00.txt>        
  8111.  
  8112.     This memo discusses the application of lossless compression technology 
  8113.     to the IP Security Architecture [IPSecArch]. Over the last few several 
  8114.     months, a number of lively debates on this topic have been held on 
  8115.     IPSec mailing list. This memo discusses the issues raised, the 
  8116.     alternatives available to resolve them and provides a set of 
  8117.     recommendations to bring resolution to the issue.                      
  8118.     The goals of the draft are to: (1) define the problem solved by the use
  8119.     of compression in the context of IPSec, (2) review the use of 
  8120.     compression and security technologies as they have been applied in 
  8121.     other layers of the protocol stack, (3) outline a set of requirements 
  8122.     for applying compression to IPSec, (4) discuss alternative methods 
  8123.     which can be implemented to meet the requirements, and (4) propose a 
  8124.     set of recommendations for consideration by the working group.         
  8125.  
  8126.   "ARIS Support for LAN Media Switching", S. Blake, Vijay Srinivasan, W. 
  8127.   Pace, A. Ghanwani, 03/27/1997, <draft-blake-aris-lan-00.txt>             
  8128.  
  8129.     ARIS (Aggregate Route-based IP Switching) [ARIS] is a protocol which, 
  8130.     in coordination with network-layer routing protocols, establishes 
  8131.     link-layer switched paths through a network of Integrated Switch 
  8132.     Routers (ISR).  This memo describes ARIS protocol mechanisms which 
  8133.     enable LAN media switching of IP packets.  In addition, this memo 
  8134.     describes the functional behavior of ISRs which are interconnected via 
  8135.     LAN media (e.g., ethernet, token ring, FDDI).  The proposed mechanisms 
  8136.     are designed to permit easy implementation using emerging LAN switching
  8137.     technology.                                                            
  8138.  
  8139.   "The Use of End System Designators in IPv6", M. Thomas, 03/27/1997, 
  8140.   <draft-thomas-ipv6-esd-00.txt>                                           
  8141.  
  8142.     There is a proposal to split unicast IPv6 addresses into two 8 byte 
  8143.     quantities.  The first 8 bytes will contain routing information which 
  8144.     is used to reach a subnetwork.  The last 8 bytes will contain a 
  8145.     identifier of a node on that subnet.  This identifier is globally 
  8146.     unique and is called an End System Designator (ESD).  The ESD (not the 
  8147.     entire 16 byte address) will be used to accept packets and identify 
  8148.     connections, among other things.                                       
  8149.  
  8150.   "A ``Classy'' Approach to Aggregation for Integrated Services", S. 
  8151.   Berson, S. Vincent, 03/27/1997, <draft-berson-classy-approach-00.txt, 
  8152.   .ps>                                                                     
  8153.  
  8154.     The current Integrated Services (IS) architecture has a fundamental 
  8155.     scaling problem in that per flow state is maintained everywhere.  Our 
  8156.     approach is to use aggregation as a technique to address this problem. 
  8157.     There is a wide spectrum of approaches towards aggregation of IS state,
  8158.     with different tradeoffs in the amount of state required.  This draft 
  8159.     describes one promising approach to aggregating IS state within defined
  8160.     regions of a network.  Service classes are configured on all of the 
  8161.     routers in a region.  At the edges of the region, routers keep detailed
  8162.     IS state and map packets into the configured traffic service classes.  
  8163.     In the interior of this region, routers need keep only a bounded amount
  8164.     of IS state.                                                           
  8165.  
  8166.   "Locating Native Internet LDAP Servers                                  
  8167.   Preliminary Draft", P. Leach, 03/27/1997, 
  8168.   <draft-leach-asid-ldap-locating-00.txt>                                  
  8169.  
  8170.     The LDAPv3 protocol (as specified in [1]) is designed to be a 
  8171.     lightweight access protocol for directory services supporting X.500 
  8172.     models. This may be the X.500 directory itself, but the LDAP 
  8173.     specification explicitly allows it to be a different directory.  Let us
  8174.     define a 'native LDAP server' to be one that is not a front end to the 
  8175.     X.500 directory service. Let us further define an 'Internet based 
  8176.     organization' as one that has a domain name, and an 'Internet LDAP 
  8177.     server' to be one containing a directory entries for such an 
  8178.     organization.                                A native LDAP server can 
  8179.     not rely upon the X.500 directory's knowledge base to locate the 
  8180.     appropriate server to service a request on an object in a part of the 
  8181.     directory tree (DIT) other than the naming context(s) it stores.       
  8182.     This draft defines a way that native Internet LDAP servers can make use
  8183.     of  the DNS's knowledge base (which it stores as 'glue' records) to 
  8184.     perform the same function, while still supporting integration with the 
  8185.     X.500 directory.                                                       
  8186.  
  8187.   "Physical Topology Framework", Ken Jones, 03/27/1997, 
  8188.   <draft-kjones-ptopo-framework-00.txt>                                    
  8189.  
  8190.     This memo defines a framework for the collection of physical topology 
  8191.     information.  Physical topology is defined as the physical 
  8192.     interconnection of communication ports between communication devices.  
  8193.     The framework allows for topology determination within and across a 
  8194.     broad spectrum of devices.  It establishes a set of guidelines for 
  8195.     topology mechanisms used to distribute and collect topology 
  8196.     information, and describes the behavior of a management station 
  8197.     required to collect topology information across a potentially large and
  8198.     diverse set of communication devices.  A companion memo will provide an
  8199.     experimental portion of the Management Information Base (MIB) which is 
  8200.     derived from this framework and allows the management workstation to 
  8201.     gather physical topology information from the devices in the network.  
  8202.  
  8203.   "Interdomain Multicast Routing Support for Integrated Services Networks",
  8204.   Deborah Estrin, S. Shenker, Bob Braden, D. Zappala, 03/27/1997, 
  8205.   <draft-zappala-multicast-routing-ar-00.txt, .ps>                         
  8206.  
  8207.     This document describes an architecture for interdomain multicast 
  8208.     routing support of integrated services networks.  The key features of 
  8209.     this architecture are a multicast route setup protocol and local route 
  8210.     construction agents.  Together, these two components enable multicast 
  8211.     routing to install alternate paths and pinned routes on behalf of 
  8212.     receivers that request these services.                                 
  8213.  
  8214.   "A Route Setup Mechanism For Multicast Routing", D. Zappala, 03/27/1997, 
  8215.   <draft-zappala-multicast-routing-me-00.txt, .ps>                         
  8216.  
  8217.     This document describes a multicast route setup protocol that can be 
  8218.     used to install alternate paths and pinned routes when they are 
  8219.     requested by receivers.  We describe the protocol, derive some of its 
  8220.     properties, and address its applicability to unicast route setup.      
  8221.  
  8222.   "Data Over Cable Service (DOCS) Radio Frequency (RF) Interface Management
  8223.   Information Base (MIB)", R. Woundy, W. Sawyer, P. Anderson, 04/14/1997, 
  8224.   <draft-anderson-docs-rf-mib-00.txt>                                      
  8225.  
  8226.     This Internet-Draft outlines the Radio Frequency (RF) Interface 
  8227.     Management Information Bases (MIBs) for high-speed data-over-cable 
  8228.     systems developed by the MCNS Data Over Cable Services working group.  
  8229.     Two Simple Network Management Protocol (SNMP) MIBs are defined.  The 
  8230.     first is the MCNS Interface MIB and defines objects that enable 
  8231.     management of the CATV MAC and PHY layer interfaces.  The second is the
  8232.     MCNS Cable Modem (CM) MIB and defines objects that enable management of
  8233.     CMs and Cable Modem Termination Systems (CMTSs).                       
  8234.  
  8235.   "RETHER : A Protocol for Real-Time Traffic Support on Ethernet", C. 
  8236.   Venkatramani, T. Chiueh, 04/14/1997, <draft-chitra-rether-00.txt>        
  8237.  
  8238.     Distributed multimedia applications require performance guarantees from
  8239.     the underlying network subsystem. Ethernet has been the dominant local 
  8240.     area network architecture in the last decade, and we believe that it 
  8241.     will remain popular because of its cost-effectiveness and the 
  8242.     availability of higher-bandwidth Ethernets. We present the design of a 
  8243.     software-based timed-token protocol called RETHER that provides 
  8244.     real-time performance guarantees to multimedia applications without 
  8245.     requiring any modifications to existing Ethernet hardware. RETHER 
  8246.     features a hybrid mode of operation to reduce the performance impact on
  8247.     non-real-time network traffic, a race-condition-free distributed 
  8248.     admission control mechanism, and an efficient token-passing scheme that
  8249.     protects the network against token loss due to node failures or 
  8250.     otherwise. Performance measurements from a prototype running on 10-Mbps
  8251.     Ethernet and 100-Mbps Fast-Ethernet indicate that up to 60 of the raw 
  8252.     bandwidth can be reserved without deteriorating the performance of 
  8253.     non-real-time traffic significantly.  This scheme is consistent with 
  8254.     the ISSLL over LANs framework described in [7].                        
  8255.  
  8256.   "UTF-8, a transformation format of ISO 10646", F. Yergeau, 09/11/1997, 
  8257.   <draft-yergeau-utf8-rev-01.txt>                                          
  8258.  
  8259.        ISO/IEC 10646-1 defines a multi-octet character set called the Uni-
  8260.        versal Character Set (UCS) which encompasses most of the world's
  8261.        writing systems. Multi-octet characters, however, are not compatible
  8262.        with many current applications and protocols, and this has led to 
  8263.     the
  8264.        development of a few so-called UCS transformation formats (UTF), 
  8265.     each
  8266.        with different characteristics.  UTF-8, the object of this memo, has
  8267.        the characteristic of preserving the full US-ASCII range, providing
  8268.        compatibility with file systems, parsers and other software that 
  8269.     rely
  8270.        on US-ASCII values but are transparent to other values. This memo
  8271.        updates and replaces RFC 2044, in particular addressing the question
  8272.        of versions of the relevant standards.                              
  8273.  
  8274.   "An Approach for Using LDAP as a Network Information Service", L. Howard,
  8275.   09/12/1997, <draft-howard-nis-schema-00.txt>                             
  8276.  
  8277.        This document describes an experimental mechanism for mapping
  8278.        entities related to TCP/IP and the UNIX system into X.500 entries so
  8279.        that they may be resolved with the Lightweight Directory Access
  8280.        Protocol [1]. A set of attribute types and object classes are
  8281.        proposed, along with specific guidelines for interpreting them.
  8282.      
  8283.        The intention is to assist the deployment of LDAP as an
  8284.        organizational nameservice. No proposed solutions are intended as
  8285.        standards for the Internet. Rather, it is hoped that a general
  8286.        consensus will emerge as to the appropriate solution to such
  8287.        problems, leading eventually to the adoption of standards. The
  8288.        proposed mechanism has already been implemented with some success.  
  8289.  
  8290.   "Switched Fabric Connection Tap (SFCT) Protocol", K. Dobbins, T. Grant, 
  8291.   J. Liessner, D. Ruffen, 04/16/1997, <draft-rfced-info-grant-00.txt>      
  8292.  
  8293.     The Switched Fabric Connection Tap (SFCT) protocol is part of the 
  8294.     InterSwitch Message Protocol (ISMP).  ISMP was designed to facilitate 
  8295.     interswitch communication within distributed connection-oriented 
  8296.     switching networks.  The SFCT protocol is used to monitor communication
  8297.     between two end stations.                                              
  8298.  
  8299.   "SBCD Protocol Specification", K. Dobbins, T. Grant, D. Ruffen, 
  8300.   04/16/1997, <draft-rfced-info-ruffen-00.txt>                             
  8301.  
  8302.     The Switch Broadcast Control and Delivery (SBCD) protocol is part of 
  8303.     the InterSwitch Message Protocol (ISMP).  ISMP was designed to 
  8304.     facilitate interswitch communication within distributed 
  8305.     connection-oriented switching networks.  The SBCD protocol is used to 
  8306.     reduce the amount of broadcast traffic across the switch fabric by 
  8307.     restricting unresolved broadcast packets to only those ports that 
  8308.     belong to the same VLAN as the source.                                 
  8309.  
  8310.   "Address Resolution and Location Discovery (ARLD) Protocol", K. Dobbins, 
  8311.   T. Grant, D. Ruffen, 04/16/1997, <draft-rfced-info-dobbins-00.txt>       
  8312.  
  8313.     The Address Resolution and Location Discovery (ARLD) protocol is part 
  8314.     of the InterSwitch Message Protocol (ISMP).  ISMP was designed to 
  8315.     facilitate interswitch communication within distributed 
  8316.     connection-oriented switching networks.  The ARLD protocol is used to 
  8317.     resolve a packet destination address when the source and destination 
  8318.     pair of a packet does not match a known connection.  It is also used to
  8319.     provide end-station address mobility between switches.                 
  8320.  
  8321.   "Loop-free Interswitch Message Path (LSMP) Protocol", K. Dobbins, T. 
  8322.   Grant, D. Ruffen, J. Benoit, 04/16/1997, <draft-rfced-info-benoit-00.txt>
  8323.  
  8324.     The Loop-Free Interswitch Message Path (LSMP) protocol is part of the 
  8325.     InterSwitch Message Protocol (ISMP).  ISMP was designed to facilitate 
  8326.     interswitch communication within distributed connection-oriented 
  8327.     switching networks.  The LSMP protocol is used to create and maintain 
  8328.     the flood path over which undirected ISMP messages are sent.           
  8329.  
  8330.   "NETBLT (Network Block Transfer Protocol)", J. White, 04/16/1997, 
  8331.   <draft-white-protocol-stack-00.txt>                                      
  8332.  
  8333.     The NETBLT protocol [RFC998] was designed as an experimental transport 
  8334.     layer protocol, intended for moving large quantities of data across a 
  8335.     wide variety of networks. It provides reliable bulk transfer with an 
  8336.     end-to-end flow-control mechanism meant to deal with network congestion
  8337.     by throttling the rate at which data is inserted into the network. 
  8338.     However, experiments with NETBLT across shared links revealed problems 
  8339.     with fairness; traffic from one connection could hog most of a link's 
  8340.     bandwidth, and there seems to be no way to prevent this under the 
  8341.     current rate-control scheme, so further application of NETBLT was not 
  8342.     pursued by its original developers.  However, NETBLT has a number of 
  8343.     characteristics which make it very attractive for use across noisy, 
  8344.     long-delay, slow-turnaround, or asymmetric communications links. Such 
  8345.     links are common in military usage, and may become more widespread with
  8346.     the development of mobile computing. NETBLT's attractive 
  8347.     characteristics include selective retransmission of lost packets, 
  8348.     potentially large transmission windows, and control of transmission 
  8349.     from the receiving, rather than the sending side; the latter makes 
  8350.     NETBLT relatively insensitive to network delays. NETBLT, with minor    
  8351.  
  8352.   "HTTP based Geo-temporal Searching (HGS).", D. van Gulik, C. Best, 
  8353.   07/14/1997, <draft-vangulik-http-search-01.txt>                          
  8354.  
  8355.     This draft specifies the first three levels of operation of an http 
  8356.     based distributed search protocol. It is designed for parallel 
  8357.     client-side searching  of geospatial  catalogues. An important design 
  8358.     objective is to minimize the impact and extra resources for catalogue 
  8359.     sites which already have existing WWW gateways and search interfaces.  
  8360.  
  8361.   "IPSEC Policy Import/Export Format", Rodney Thayer, Naganand Doraswamy, 
  8362.   06/24/1997, <draft-thayer-sec-exp-01.txt>                                
  8363.  
  8364.     Under certain conditions it is necessary to configure hosts running IP 
  8365.     Security [RFC-1825] with security parameters and other information in 
  8366.     an out-of-band manner.  This draft defines a file format that may be 
  8367.     used to exchange such information via removable media or distribution 
  8368.     via a web server.                                                      
  8369.     THIS DOCUMENT EXPIRES DECEMBER 1997.                                   
  8370.  
  8371.   "Sieve -- a Mail Filtering Language", T. Showalter, 10/27/1997, 
  8372.   <draft-showalter-sieve-02.txt>                                           
  8373.  
  8374.        This document describes a mail filtering language for filtering
  8375.        messages at time of final delivery.  It is designed to be 
  8376.     independent
  8377.        of protocol, and implementable on either a mail client or mail
  8378.        server.  It is meant to be extensible, simple, and independent of
  8379.        access protocol, mail architecture, and operating system.  It is
  8380.        suitable for running on a mail server where users may not be allowed
  8381.        to execute arbitrary programs, such as on black box IMAP servers, as
  8382.        it has no variables, loops, or ability to shell out to external
  8383.        programs.                                                           
  8384.  
  8385.   "Hierarchical HTTP Routing Protocol", Jeff Mogul, V. Valloppillil, 
  8386.   04/22/1997, <draft-vinod-icp-traffic-dist-00.txt>                        
  8387.  
  8388.     Recent interest in finding solutions for traffic problems stemming from
  8389.     HTTP have centered around the use of cooperating proxy-caches.         
  8390.     We contend that by using a deterministic, hash-based approach for 
  8391.     routing URLs within an 'array' of proxy servers, many of the benefits 
  8392.     of alternative cache cooperation protocols (such as ICP) may be 
  8393.     realized.     As an example of such an implementation we propose the 
  8394.     use of 'Proxy Client Configuration Files' between proxy servers in 
  8395.     order to exchange routing information.  This implementation is 
  8396.     motivated in part by the adoption of this file by existing, popular web
  8397.     browsers to provide intelligent URL request routing.                   
  8398.     This draft discusses adopting this well-understood, widely implemented 
  8399.     browser protocol by web proxies in order to facilitate intelligent 
  8400.     routing of requests within a network of proxy servers.                 
  8401.  
  8402.   "HTTP/1.1 Operation without a Clock", J Mogul, R. Gray, Ari Luotonen, 
  8403.   04/22/1997, <draft-lawrence-http-noclock-00.txt>                         
  8404.  
  8405.     This memo describes a problem with the current Proposed Standard for 
  8406.     HTTP/1.1 found as a result of implementation experience.  A web server 
  8407.     may be implemented in an embedded system as a network user interface.  
  8408.     Often the embedded system is one which has no other use for a real-time
  8409.     clock, and/or the web interface is being added to an existing device 
  8410.     which has no clock.  Without a clock, no accurate HTTP Date header can 
  8411.     be generated.    This memo examines the implications of this situation 
  8412.     for the operation of HTTP/1.1 origin servers, proxies, and clients, and
  8413.     proposes changes to the HTTP/1.1 specification to permit compliant 
  8414.     operation in such systems.                                             
  8415.  
  8416.   "The Java LDAP Application Program Interface", Tim Howes, Mark Smith, R. 
  8417.   Weltman, 04/23/1997, <draft-weltman-java-ldap-00.txt>                    
  8418.  
  8419.     This document defines a java language application program interface to 
  8420.     the lightweight directory access protocol (LDAP), in the form of a 
  8421.     class library. It complements but does not replace RFC 1823 ([9]), 
  8422.     which describes a C language application program interface.            
  8423.  
  8424.   "XODL: External Object Description Language", B. Long, 04/29/1997, 
  8425.   <draft-long-external-obj-lang-01.txt>                                    
  8426.  
  8427.     This document describes a data structure (XODL: Object Description 
  8428.     Language) and an associated method which, together, provide a means of 
  8429.     representing situations or types of situations.  It can thus be used to
  8430.     represent objects, events, or systems of objects and events or types of
  8431.     objects, events or systems.  Objects represented can be computer data 
  8432.     objects ('stack', 'word processor', 'user interface', etc.) or 'real' 
  8433.     objects such as computers, networks, users, and so on.                 
  8434.  
  8435.   "Comparison of Tag Switching and Cell Switch Router", Y. Katsube, Hiroshi
  8436.   Esaki, Y. Ohba, 04/25/1997, <draft-ohba-tagsw-vs-csr-00.txt>             
  8437.  
  8438.     Tag Switching and Cell Switch Router are layer integration technologies
  8439.     between L2 and L3 to provide high-speed cut-through mechanisms for L3 
  8440.     packet transfer by mapping between L3 and L2 datagram labels. TDP and 
  8441.     FANP, used in Tag Switching and Cell Switch Router, respectively, are 
  8442.     protocols that notify the mapping information between peer routers.  
  8443.     Although the objectives of both technologies are the same, there are 
  8444.     several differences in methods for achieving the objective. This memo 
  8445.     compares the two technologies and discusses how to merge them.         
  8446.  
  8447.   "Schema for Storing Calendaring Information in a Directory Service", A. 
  8448.   Dun, D. Hennessy, 04/25/1997, <draft-dun-calsch-schema-00.txt>           
  8449.  
  8450.     The Lightweight Directory Access Protocol [1][2] defines a standard 
  8451.     protocol for accessing diverse directory services. One common use of a 
  8452.     directory service is the location of application services, among which 
  8453.     are a user's calendar and a user's free busy time.                     
  8454.     This document defines a set of object classes and attributes for 
  8455.     storing information including URLs to the user's calendar and free/busy
  8456.     time.                                                                  
  8457.  
  8458.   "E-Mail Headers to Facilitate Mailing List Subscriptions and 
  8459.   Unsubscriptions", B. Costales, 08/19/1997, 
  8460.   <draft-costales-subscribe-01.txt>                                        
  8461.  
  8462.     The number of ways to subscribe-to (and to unsubscribe-from) e-mail 
  8463.     mailing lists is as varied as the number of programmers designing 
  8464.     mailing list software. For some lists, for example, users (un)subscribe
  8465.     by sending a request to <listname>-request@host.domain.  For others 
  8466.     lists the address is majordomo@host.domain with the request to 
  8467.     (un)subscribe embedded in the message body. Yet others set up special 
  8468.     hosts to satisfy this need, such as <listname>@list-off.domain.  In 
  8469.     this Internet Draft we offer two new e-mail headers intended to make 
  8470.     mailing list subscription and unsubscription easier and more uniform: 
  8471.     List-Subscribe and List-Unsubscribe.                                   
  8472.  
  8473.   "DHCP Options For Host System Characteristics", M. Henry, E. Dittert, 
  8474.   04/28/1997, <draft-dittert-host-sys-char-00.txt>                         
  8475.  
  8476.     The interoperability of configuration services based on the Dynamic 
  8477.     Host Configuration Protocol (DHCP) [1] in an environment of 
  8478.     heterogeneous clients depends on clients accurately identifying 
  8479.     themselves and their relevant characteristics to configuration servers.
  8480.     The class identifier provided through DHCP option 60 [2] helps in this 
  8481.     regard, but such identifiers essentially only enable clients and 
  8482.     servers that are 'good friends' to find each other. This draft proposes
  8483.     the definition of two options that convey particular, generally useful 
  8484.     information about the client system.  This enables all servers to 
  8485.     recognize this information, and is a step toward a richer form of 
  8486.     interoperability for configuration services.                           
  8487.  
  8488.   "THE TRANSMISSION OF IP OVER THE VERTICAL BLANKING INTERVAL OF A 
  8489.   TELEVISION SIGNAL", R. Panabaker, C. Witty, 10/14/1997, 
  8490.   <draft-panabaker-ip-vbi-01.txt>                                          
  8491.  
  8492.     This is an Internet-Draft, which describes a method for broadcasting
  8493.     multicast IP data using the vertical blanking interval of a television
  8494.     signal.  It includes a description for compressing multicast IP headers
  8495.     on unidirectional networks, a framing protocol identical to SLIP, and a
  8496.     forward error correction scheme for the NABTS standard.                
  8497.  
  8498.   "SNDM Protocol Specification", K. Dobbins, J. Livingston, D. Ruffen, T. 
  8499.   Grant, 04/29/1997, <draft-rfced-info-livingston-00.txt>                  
  8500.  
  8501.     The Switch Neighbor Discovery and Maintenance (SNDM) protocol is part 
  8502.     of the InterSwitch Message Protocol (ISMP).  ISMP was designed to 
  8503.     facilitate interswitch communication within distributed 
  8504.     connection-oriented switching networks.  Switches use the SNDM protocol
  8505.     to discover their neighboring switches and establish the topology of 
  8506.     the switch fabric.                                                     
  8507.  
  8508.   "IP Header Compression over PPP", Stephen Casner, C. Bormann, M. Engan, 
  8509.   08/21/1997, <draft-engan-ip-compress-01.txt>                             
  8510.  
  8511.           This document describes an  option  for  negotiating  the  use  
  8512.     of
  8513.           header  compression on IP datagrams transmitted over the 
  8514.     Point-to-
  8515.           Point Protocol [RFC1661]. It defines extensions to the PPP 
  8516.     Control
  8517.           Protocols for IPv4 and IPv6 [RFC1332, RFC2023]. Header 
  8518.     compression
  8519.           may be applied to IPv4 and IPv6 datagrams in combination with 
  8520.     TCP,
  8521.           UDP and RTP transport protocols as specified in [IPHC] and 
  8522.     [CRTP].                                                                
  8523.  
  8524.   "Security-Oriented Extension to Mobile IP (SOMIP)", M. Chuah, Y. Li, 
  8525.   04/29/1997, <draft-chuahli-mobileip-somip-00.txt>                        
  8526.  
  8527.     This document proposes an extension to the Mobile IP base protocol.  
  8528.     The purpose of this extension is to ease the key management problem 
  8529.     among mobility agents, and to reduce the number of distant 
  8530.     registrations.                                                         
  8531.  
  8532.   "IMAP4 Namespace", C Newman, M. Gahrns, 10/21/1997, 
  8533.   <draft-gahrns-imap-namespace-04.txt>                                     
  8534.  
  8535.     
  8536.        IMAP4[RFC-2060] does not define a default server namespace. As a
  8537.        result, two common namespace models have evolved:
  8538.     
  8539.        The 'Personal Mailbox' model, in which the default namespace that is
  8540.        presented consists of only the user's personal mailboxes. To access
  8541.        shared mailboxes, the user must use an escape mechanism to reach
  8542.        another namespace.
  8543.     
  8544.        The 'Complete Hierarchy' model, in which the default namespace that
  8545.        is presented includes the user's personal mailboxes along with any
  8546.        other mailboxes they have access to.
  8547.          
  8548.        These two models, create difficulties for certain client operations.
  8549.        This document defines a NAMESPACE command that allows a client to
  8550.        discover the prefixes of namespaces used by a server for personal
  8551.        mailboxes, other users' mailboxes, and shared mailboxes.  This
  8552.        allows a client to avoid much of the manual user configuration that
  8553.        is now necessary when mixing and matching IMAP4 clients and servers.
  8554.                                                                            
  8555.  
  8556.   "A Protocol for the Transmission of Net News Articles over IP multicast",
  8557.   H. Rupp, 09/16/1997, <draft-rfced-exp-rupp-03.txt>                       
  8558.  
  8559.        Mcntp (Multicast News Transfer Protocol) provides a way to use the 
  8560.     IP
  8561.        multicast infrastructure to transmit NetNews articles between news
  8562.        servers. Doing so will reduce the bandwidth that is actually needed
  8563.        for transmission of articles which is mostly done via NNTP. This 
  8564.     does
  8565.        not affect how news reading clients communicate with servers.       
  8566.  
  8567.   "Using UTF-8 for non-ASCII Characters in URLs", Larry Masinter, 
  8568.   05/02/1997, <draft-masinter-url-i18n-00.txt>                             
  8569.  
  8570.     Traditionally, URLs have been written in ASCII and used both as a 
  8571.     method of transcription and identification, but also in advertising, 
  8572.     magazines and newspapers. This document specifies a uniform way of 
  8573.     representing non-ASCII scripts in URLs so that they can be used for the
  8574.     world's languages.                                                     
  8575.  
  8576.   "PKCS #10: Certification Request Syntax                                 
  8577.   Version 1.5", B. Kaliski, 10/21/1997, 
  8578.   <draft-hoffman-pkcs-certif-req-03.txt>                                   
  8579.  
  8580.     This document describes a syntax for certification requests.           
  8581.  
  8582.   "PKCS #1: RSA Encryption Version 1.5", B. Kaliski, 10/21/1997, 
  8583.   <draft-hoffman-pkcs-rsa-encrypt-03.txt>                                  
  8584.  
  8585.     This document describes a method for encrypting data using the RSA
  8586.        public-key cryptosystem.                                            
  8587.  
  8588.   "PKCS #7: Cryptographic Message Syntax Version 1.5", B. Kaliski, 
  8589.   10/21/1997, <draft-hoffman-pkcs-crypt-msg-03.txt>                        
  8590.  
  8591.        This document describes a general syntax for data that may have
  8592.        cryptography applied to it, such as digital signatures and digital
  8593.        envelopes. The syntax admits recursion, so that, for example, one
  8594.        envelope can be nested inside another, or one party can sign some
  8595.        previously enveloped digital data.  It also allows arbitrary
  8596.        attributes, such as signing time, to be authenticated along with the
  8597.        content of a message, and provides for other attributes such as
  8598.        countersignatures to be associated with a signature. A degenerate
  8599.        case of the syntax provides a means for disseminating certificates
  8600.        and certificate-revocation lists.                                   
  8601.  
  8602.   "Creating 40-Bit Keys for DES", Russ Housley, Paul Hoffman, 05/14/1997, 
  8603.   <draft-hoffman-des40-00.txt>                                             
  8604.  
  8605.     This document describes an method for shortening DES keys from 56 bits 
  8606.     to 40 bits. The shortened keys are generally known as 'DES-40'. The 
  8607.     motivation for this weakening is that some localities (such as the 
  8608.     United States) give special preference to applications that use 40-bit 
  8609.     keys. The weakened keys are then used with the DES encryption algorithm
  8610.     in the same manner as full-strength keys.                              
  8611.     There are many possible methods for reducing a 56-bit key to a 40-bit 
  8612.     key. The method in this draft was chosen because one method is needed 
  8613.     for interoperability. Further, this method has been known to 
  8614.     occaisionally have been approved for export from the United States.    
  8615.  
  8616.   "HTTP and HTML Metadata Linking Mechanism", A. Daviel, 05/15/1997, 
  8617.   <draft-daviel-metadata-link-00.txt>                                      
  8618.  
  8619.     This memo describes a method of linking resource metadata to resource 
  8620.     objects using HTTP headers or HTML hyperlinks. The method uses features
  8621.     which exist in HTTP/1.0 and HTML 2.0, namely the Link element, to 
  8622.     reference metadata of arbitrary MIME type from resources of arbitrary 
  8623.     MIME type.                                                             
  8624.  
  8625.   "Dynamical routing (unicast and multicast) for the Ipv6 protocol", W. 
  8626.   Fritsch, H. Seifert, 05/20/1997, <draft-fritsche-ipv6-multicast-01.txt>  
  8627.  
  8628.     Future communication networks will be based more and more on a 
  8629.     dynamically changing network topology.  Therefore it is advantageous, 
  8630.     to have routing mechanisms, which will dynamically adapt their routing 
  8631.     decisions to these topology changes.  This document describes a set of 
  8632.     network protocols, which realize such a dynamical routing of unicast 
  8633.     and multicast packets within communication networks based on IPv6.  All
  8634.     used routing algorithms will be immediately executed at the occurrence 
  8635.     of any topology changes and will therefore have already complete 
  8636.     routing information at the receipt of data packets.                    
  8637.     For the unicasting the Shortest Path First (SPF) routing algorithm has 
  8638.     be chosen.  This algorithm calculates the shortest, and therefore the 
  8639.     optimal routing paths within the routing area, by which it is 
  8640.     sufficient for a router, to compute a single routing tree for the whole
  8641.     area.               For the multicasting the Minimum Spanning Tree 
  8642.     (MST) routing algorithm has been chosen.  This distributed algorithm 
  8643.     prevents the occurrence of endless routing loops, offers for 
  8644.     distributed Address Groups nearly optimal results in saving network 
  8645.     bandwidth, and needs                                                   
  8646.  
  8647.   "Japanese Message Signing Procedure with Security Multipart", K. 
  8648.   Yamamoto, 05/19/1997, <draft-kazu-jmsg-sign-secmime-00.txt>              
  8649.  
  8650.     This memo defines a signing procedure for Japanese message in the 
  8651.     context of security multipart. The procedure guarantees signature 
  8652.     validity even if messages are processed through message transfer agents
  8653.     which carelessly transform character set encodings.                    
  8654.     To sign Japanese message digitally, local forms such as EUC/Japanese, 
  8655.     Shift-JIS, etc., are first converted into the transfer form, 
  8656.     ISO-2022-JP with an appropriate set of MIME headers. Then it is 
  8657.     duplicated into two objects. The first object is transformed into the 
  8658.     signature form defined in this memo and a detached digital signature is
  8659.     calculated over it. A 'Multipart/Signed' part is created with the 
  8660.     second object and the detached digital signature. Japanese text is 
  8661.     verified as the signature form instead of the transfer form.           
  8662.     To encrypt Japanese message, the transfer form, ISO-2022-JP with an 
  8663.     appropriate set of MIME headers, is used.                              
  8664.  
  8665.   "Multi-signature Extensions for PGP/MIME", K. Yamamoto, 05/19/1997, 
  8666.   <draft-kazu-pgpmime-multisig-00.txt>                                     
  8667.  
  8668.     PGP/MIME provides single signature service of PGP in the context of 
  8669.     MIME, however, multiple signature service is desired for usability and 
  8670.     flexibility. For this purpose, this memo defines 
  8671.     'Multipart/PGP-Signature' used as the 'protocol' parameter and the 
  8672.     content type of the second part of 'Multipart/Signed'.                 
  8673.     Canonical MIME format used in PGP/MIME is reasonable but it is not 
  8674.     enough for some kinds of MIME objects, particularly for ISO 2022 text. 
  8675.     Thus, this memo extends the 'micalg' parameter syntax as 
  8676.     'pgp-<hash-symbol>+<canform-symbol>' so that <canform-symbol> can 
  8677.     specify more specific canonicalization for signature calculation.      
  8678.  
  8679.   "Remote Passphrase Authentication", G. Brown, 05/19/1997, 
  8680.   <draft-petke-remote-pass-auth-00.txt>                                    
  8681.  
  8682.     Remote Passphrase Authentication provides a way to authenticate a user 
  8683.     to a service by using a pass phrase over an insecure network, without 
  8684.     revealing the pass phrase to eavesdroppers. In addition, the service 
  8685.     need not know and does not learn the user's pass phrase, making this 
  8686.     scheme useful in distributed environments where it would be difficult 
  8687.     or inappropriate to trust a service with a pass phrase database or to 
  8688.     allow the server to learn enough to masquerade as the user in a future 
  8689.     authentication attempt.                                                
  8690.     This scheme was inspired by Dave Raggett's Mediated Digest 
  8691.     Authentication, draft-ietf-http-mda-00.txt.                            
  8692.     This specification is divided into five parts. Part Zero contains an 
  8693.     extended introduction to the problem and potential solutions. Part One 
  8694.     explains the mechanism. Part Two explains how to incorporate the 
  8695.     mechanism into HTTP. Part Three explains the protocol between the 
  8696.     service and deity. Part Four explains the GSS-API token formats. Feel 
  8697.     free to start with Part One; Part Zero provides background information 
  8698.     and is not a prerequisite for Part One.                                
  8699.  
  8700.   "AP -- Access Protocol", R. Earhart, 05/19/1997, 
  8701.   <draft-earhart-ap-spec-00.txt>                                           
  8702.  
  8703.     The Access Protocol defines a standard extensible framework upon which 
  8704.     application-specific protocols may be layered, providing a piece of 
  8705.     infrastructure for a common class of internet protocols.               
  8706.  
  8707.   "VLS Protocol Specification", K. Dobbins, L. Kane, 05/21/1997, 
  8708.   <draft-rfced-info-kane-00.txt>                                           
  8709.  
  8710.     The Virtual LAN Link State Protocol (VLSP) is part of the InterSwitch 
  8711.     Message Protocol (ISMP).  ISMP was designed to facilitate interswitch 
  8712.     communication within distributed determine and maintain a fully 
  8713.     connected mesh topology graph of the switch fabric.  Each switch 
  8714.     maintains an identical database describing the topology.  
  8715.     Call-originating switches use the topology database to determine the 
  8716.     path over which to route a call connection.                            
  8717.     VLSP provides support for equal-cost multipath routing, and 
  8718.     recalculates routes quickly in the face of topological changes, 
  8719.     utilizing a minimum of routing protocol traffic.                       
  8720.  
  8721.   "State Tokens and Preconditions for HTTP", Jim Whitehead, Y. Goland, 
  8722.   05/22/1997, <draft-goland-state-token-00.txt>                            
  8723.  
  8724.     There are times when a principal will want to predicate successful 
  8725.     execution of a method on the current state of a resource. While 
  8726.     HTTP/1.1 provides a mechanism for conditional execution of methods 
  8727.     using entity tags via the 'If-Match' and 'If-None-Match' headers, the 
  8728.     mechanism is not sufficiently extensible to express conditional 
  8729.     statements involving more generic state indicators, such as lock 
  8730.     tokens.                             This draft defines the term 'state 
  8731.     token' as an identifier for a state of a resource. This draft defines 
  8732.     requirements for state tokens and provides a state token syntax, along 
  8733.     with two new headers which are used to express method preconditions 
  8734.     using state tokens.                                                    
  8735.  
  8736.   "Use of Label Switching With RSVP", Bruce Davie, Y Rekhter, E. Rosen, 
  8737.   05/28/1997, <draft-davie-mpls-rsvp-00.txt>                               
  8738.  
  8739.     Multiprotocol Label Switching (MPLS) allows labels to be bound to 
  8740.     various granularities of forwarding information, including application 
  8741.     flows. In this document we present a specification for allocating and 
  8742.     binding labels to RSVP flows, and distributing the appropriate binding 
  8743.     information using RSVP messages.                                       
  8744.  
  8745.   "IP Address Resolution and ATM Signaling for MPLS over ATM SVC services",
  8746.   Y Rekhter, Y. Katsube, Hiroshi Esaki, K. Nagami, P. Doolan, 05/29/1997, 
  8747.   <draft-katsube-mpls-over-svc-00.txt>                                     
  8748.  
  8749.     Enabling interconnection of ATM Label Switching Routers (ATM-LSRs) over
  8750.     standard ATM switch networks is desirable in order to introduce MPLS 
  8751.     technology into emerging ATM-LAN/WAN platform.  This draft describes 
  8752.     how ATM-LSRs may interoperate with other ATM-LSRs over ATM UNI SVC 
  8753.     services.  The two aspects of the problem that we address are ATM 
  8754.     address (of target ATM-LSR) resolution and SVC to label binding.       
  8755.  
  8756.   "Media-independent Error Correction using RTP", P. Long, R. McKenzie, D. 
  8757.   Budge, W. Mills, W. Diss, 06/02/1997, 
  8758.   <draft-budge-media-error-correction-00.txt>                              
  8759.  
  8760.     This document specifies a media-independent error-correction scheme 
  8761.     using the Real-Time Transport Protocol (RTP), along with the payload 
  8762.     format for encapsulating both error-correction signaling and media 
  8763.     bitstreams in RTP. It enables the reconstruction of lost packets across
  8764.     a connectionless transport such as RTP over UDP. The goal of this 
  8765.     scheme is to maximize isochrony, the regular and timely delivery of 
  8766.     data, with minimal bandwidth, latency, and computational costs.        
  8767.  
  8768.   "Plaintext Password SASL Mechanism and Transition Codes", C Newman, 
  8769.   07/20/1997, <draft-newman-sasl-plaintrans-03.txt>                        
  8770.  
  8771.          While plaintext passwords have very poor security characteristics
  8772.          by themselves, there are a number of contexts where they are 
  8773.     useful
  8774.          or necessary.  This defines a plaintext password mechanism for 
  8775.     SASL
  8776.          [SASL] which is intended to be used in combination with an 
  8777.     external
  8778.          encryption layer, as a transition mechanism from a legacy
  8779.          authentication database, or to use (insecurely) a legacy
  8780.          authentication database which can not practically be replaced.
  8781.      
  8782.          In hopes of promoting the future elimination of unencrypted
  8783.          plaintext passwords, this defines error codes for use with POP3 
  8784.     and
  8785.          IMAP4: one to indiciate the need for a transition to a stronger
  8786.          mechanism, a second to indicate that a SASL mechanism is too weak
  8787.          for per-user security policy for a given service, and a third to
  8788.          indicate that a SASL mechanism is only accepted in combination 
  8789.     with
  8790.          an external strong encryption mechanism.  Any protocol offering 
  8791.     the
  8792.          PLAIN mechanism SHOULD also support equivalent error codes.
  8793.                                                                            
  8794.  
  8795.   "The IP Network Address Translator (NAT)", Pyda Srisuresh, Kjeld Egevang,
  8796.   09/02/1997, <draft-rfced-info-srisuresh-03.txt>                          
  8797.  
  8798.     Basic Network Address Translation or Basic NAT is a feature by
  8799.        which IP addresses are mapped from one group to another, transparent
  8800.        to users. Network Address Port Translation, or NAPT is an extension
  8801.        to Basic NAT, in that many network addresses and their TCP/UDP ports
  8802.        are translated to a single network address and its TCP/UDP ports.   
  8803.  
  8804.   "Interoperation Between Distinct Types of Label Switched Paths", Y. 
  8805.   Katsube, Hiroshi Esaki, 06/06/1997, 
  8806.   <draft-katsube-interop-between-lsps-00.txt>                              
  8807.  
  8808.     Label Switching Routers are able to handle several distinct types of 
  8809.     Label Switched Paths (LSPs) depending on the triggers for establishing 
  8810.     or releasing LSPs or the granularity of the flow that are dedicated to 
  8811.     each of the LSPs.  This memo first analyzes characteristics of 
  8812.     individual types of LSPs, and discusses possible interoperation 
  8813.     scenario between them.                                                 
  8814.  
  8815.   "Hot Standby Router Protocol (HSRP)", Tony Li, B. Cole, D. Li, P. Morton,
  8816.   10/06/1997, <draft-li-hsrp-01.txt>                                       
  8817.  
  8818.     The memo specifies the Hot Standby Router Protocol (HSRP).  The goal
  8819.        of the protocol is to allow hosts to appear to use a single router
  8820.        and to maintain connectivity even if the actual first hop router 
  8821.     they
  8822.        are using fails.  Multiple routers participate in this protocol and
  8823.        in concert create the illusion of a single virtual router.  The
  8824.        protocol insures that one and only one of the routers is forwarding
  8825.        packets on behalf of the virtual router.  End hosts forward their
  8826.        packets to the virtual router.
  8827.      
  8828.        The router forwarding packets is known as the active router.  A
  8829.        standby router is selected to replace the active router should it
  8830.        fail. The protocol provides a mechanism for determining active and
  8831.        standby routers, using the IP addresses on the participating 
  8832.     routers.
  8833.        If an active router fails a standby router can take over without a
  8834.        major interruption in the host's connectivity.  This memo also
  8835.        discusses the ARP, MAC address, and security issues with this
  8836.        protocol.                                                           
  8837.  
  8838.   "Uniform Resource Locators for Television Broadcasts", D. Zigmond, 
  8839.   06/10/1997, <draft-zigmond-tv-url-00.txt>                                
  8840.  
  8841.     World-Wide Web browsers are starting to appear on a variety of consumer
  8842.     electronic devices, such as television sets and television set-top 
  8843.     boxes, which are capable of receiving television programming from 
  8844.     either terrestrial broadcast, satellite broadcast, or cable. On these 
  8845.     devices, some of the URL schemes described in [1] are inappropriate. 
  8846.     For example, many of these devices lack local storage, so the 'file' 
  8847.     scheme is of little use. This draft proposes a new URL scheme for 
  8848.     uniquely identifying streams of television broadcasts on such devices. 
  8849.  
  8850.   "A Clarification for Textual Conventions in SMIv2", David Perkins, 
  8851.   06/12/1997, <draft-perkins-clartc-00.txt>                                
  8852.  
  8853.     This memo is informational.  It specifies a clarification of version 2 
  8854.     of the SNMP SMI, a standard for the Internet community, which is 
  8855.     defined by RFCs 1902[1], 1903[2], and 1904[3]. The clarification is to 
  8856.     fix a perceived inconsistency in the definition of the 
  8857.     TEXTUAL-CONVENTION construct.  This problem is resolved by replacement 
  8858.     text for section 3.5 of RFC 1903.                                      
  8859.  
  8860.   "Support for Large Integers in SNMP", David Perkins, 06/12/1997, 
  8861.   <draft-perkins-bigint-00.txt>                                            
  8862.  
  8863.     This memo is informational.  It specifies an approach to add 64-bit 
  8864.     signed and unsigned integer types to versions 1 and 2 of the SNMP 
  8865.     SMI[1][2][3][4][5][6], and versions 1 and 2 of the SNMP 
  8866.     protocol[7][8][9] without changes. Thus, this addition requires no 
  8867.     modifications to existing SNMP MIB compilers, and no changes to 
  8868.     existing SNMP protocol engines used in SNMP agents and SNMP management 
  8869.     applications.                           This memo does not specify a 
  8870.     standard for the Internet community.                                   
  8871.  
  8872.   "The BITS Pseudotype", David Perkins, 06/12/1997, 
  8873.   <draft-perkins-bits-00.txt>                                              
  8874.  
  8875.     This memo is informational.  It specifies replacement text for version 
  8876.     2 of the SNMP SMI, which is defined by RFCs 1902[1], 1903[2], and 
  8877.     1904[3], to fix the incorrect usage of ASN.1 to specify a BITS 
  8878.     pseudotype.  The BITS pseudotype must have the look and functions of an
  8879.     ASN.1 type in the following constructs allowed in SMIv2 format MIB 
  8880.     modules: OBJECT-TYPE, SEQUENCE, MODULE-COMPLIANCE, AGENT-CAPABILITIES, 
  8881.     TEXTUAL-CONVENTION, and type assignments.  The ASN.1 macros defined in 
  8882.     RFCs 1902, 1903, and 1904 do not support the requirements.             
  8883.  
  8884.   "Support for Floating-Point in SNMP", David Perkins, 06/12/1997, 
  8885.   <draft-perkins-float-00.txt>                                             
  8886.  
  8887.     This memo is informational.  It specifies an approach to add 
  8888.     floating-point types to versions 1 and 2 of the SNMP 
  8889.     SMI[1][2][3][4][5][6], and versions 1 and 2 of the SNMP 
  8890.     protocol[7][8][9] without changes. Thus, this addition requires no 
  8891.     modifications to existing SNMP MIB compilers, and no changes to 
  8892.     existing SNMP protocol engines used in SNMP agents and SNMP management 
  8893.     applications.                           This memo does not specify a 
  8894.     standard for the Internet community.                                   
  8895.  
  8896.   "Firewall Traversal authorization system", M. Richardson, K. Martius, 
  8897.   07/10/1997, <draft-richardson-ipsec-traversal-01.txt>                    
  8898.  
  8899.     This document describes a public key certificate mechanism to authorize
  8900.     traversal of multiple security gateways (firewalls). This work is 
  8901.     independant of transport layer in concept, and could apply to IPsec, 
  8902.     TLS, or SecSH. It is applied here to IPsec. The SPKI certificate format
  8903.     is used here.                                                          
  8904.  
  8905.   "Description of the EP2 Cipher", Peter Gutmann, 06/16/1997, 
  8906.   <draft-rfced-info-gutmann-00.txt>                                        
  8907.  
  8908.     The EP2 cipher is a block cipher that is useful in many cryptographic 
  8909.     applications. It is believed to be interoperable with the RC2 cipher 
  8910.     froim RSA Data Security, In., which has been specified for use in many 
  8911.     Internet Protocols.                                                    
  8912.  
  8913.   "Virtual Server Protocol", I. Jeyasubramanian, 06/16/1997, 
  8914.   <draft-jeya-virtual-server-00.txt>                                       
  8915.  
  8916.     This document specifies a protocol termed the 'Virtual server 
  8917.     protocol', which makes an end-user automatically connect to a least 
  8918.     loaded Server among the list of Mirror/alternate Servers available for 
  8919.     a particular Service, advertised in the Internet.                      
  8920.     Using this protocol, the clients accessing the Internet no longer need 
  8921.     to know the existence of mirror servers available for a particular 
  8922.     service.                                                               
  8923.  
  8924.   "Internet Security Label (ISL)", T. Bartee, N. Alvarez, C. Nunley, 
  8925.   06/23/1997, <draft-tbnadn-sec-label-00.txt>                              
  8926.  
  8927.     This document describes the Internet Security Label (ISL).  ISL 
  8928.     provides a mechanism for encoding security (sensitivity) parameters.  
  8929.     The ISL is intended to be a layer-independent security mechanism.  It 
  8930.     can be used with all current versions of the Internet Protocol (IP), 
  8931.     including IPv4 and IPv6 as well as the IP Security Protocols (IPSEC), 
  8932.     the encapsulating Security Payload (ESP) and the Authentication Header 
  8933.     (AH). Other protocols which use a security label can also use the ISL 
  8934.     encoding standard including IPX.                                       
  8935.  
  8936.   "Application Protocol Design Principles", C Newman, 07/29/1997, 
  8937.   <draft-newman-protocol-design-01.txt>                                    
  8938.  
  8939.          There are a number of design principles which come into play over
  8940.          and over again when designing application protocols.  Many of 
  8941.     these
  8942.          are entrenched in IETF lore and spread by word of mouth.  Most 
  8943.     have
  8944.          been learned the hard way many times.
  8945.      
  8946.          This is an attempt to codify some of these principles so they can
  8947.          be referenced rather than spread by word of mouth.  The author has
  8948.          not invented any of these ideas and while the exercise of finding
  8949.          the originator of the ideas would be interesting, it is not deemed
  8950.          necessary for this project.
  8951.      
  8952.          Many of these principles have a much wider scope than application
  8953.          protocol design.  However, the author's primary experience is with
  8954.          application protocols and examples provided usually involve
  8955.          application protocols or elements.
  8956.      
  8957.          [Disclaimer: this is a preliminary draft.  Some of the case 
  8958.     studies
  8959.          and exceptions need tuning.  Suggestions welcome.]
  8960.                                                                            
  8961.  
  8962.   "IETF Policy on Character Sets and Languages", Harald Alvestrand, 
  8963.   10/21/1997, <draft-alvestrand-charset-policy-02.txt>                     
  8964.  
  8965.         The Internet is international.
  8966.      
  8967.         With the international Internet follows an absolute requirement to
  8968.         interchange data in a multiplicity of languages, which in turn
  8969.         utilize a bewildering number of characters.
  8970.      
  8971.         This document is (INTENDED TO BE) the current policies being
  8972.         applied by the Internet Engineering Steering Group towards the
  8973.         standardization efforts in the Internet Engineering Task Force in
  8974.         order to help Internet protocols fulfil these requirements.
  8975.      
  8976.         The document is very much based upon the recommendations of the
  8977.         IAB Character Set Workshop of February 29-March 1, 1996, which is
  8978.         documented in RFC 2130 [WR]. This document attempts to be concise,
  8979.         explicit and clear; people wanting more background are encouraged
  8980.         to read RFC 2130.
  8981.     
  8982.         The document uses the terms 'MUST', 'SHOULD' and 'MAY', and their
  8983.         negatives, in the way described in [RFC 2119]. In this case,       
  8984.  
  8985.   "PACE(TM) Technology's Ethernet Interactive Access Algorithm", J. Hickey,
  8986.   06/24/1997, <draft-rfced-info-hickey-00.txt>                             
  8987.  
  8988.     PACE technology is designed to provide backwards-compatible 
  8989.     modifications to Ethernet to support multimedia applications.  PACE 
  8990.     Technology's Ethernet Interactive Access [1] uses a modified 802.3 MAC 
  8991.     access algorithm to minimise access latency when communicating to 
  8992.     standard 802.3 MAC devices.  This access algorithm is documented here 
  8993.     via pseudo code in a manner similar to the 802.3 MAC standard.         
  8994.  
  8995.   "A Description of the RC2(r) Encryption Algorithm", R. Rivest, 
  8996.   06/24/1997, <draft-rivest-rc2desc-00.txt>                                
  8997.  
  8998.     This draft is an RSA Laboratories Technical Note. It is meant for 
  8999.     informational use by the Internet community.                           
  9000.     This memo describes a conventional (secret-key) block encryption 
  9001.     algorithm, called RC2, which may be considered as a proposal for a DES 
  9002.     replacement. The input and output block sizes are 64 bits each. The key
  9003.     size is variable, from one byte up to 128 bytes, although the current 
  9004.     implementation uses eight bytes.                                       
  9005.     The algorithm is designed to be easy to implement on 16-bit 
  9006.     microprocessors. On an IBM AT, the encryption runs about twice as fast 
  9007.     as DES (assuming that key expansion has been done).                    
  9008.  
  9009.   "PPP/IPCP Extension for Word Alignment of IP Datagrams", P. Martin, 
  9010.   07/01/1997, <draft-rfced-info-martin-00.txt>                             
  9011.  
  9012.     The Point-to-Point Protocol (PPP) [1] provides a standard method for 
  9013.     transporting multi-protocol datagrams over point-to-point links.  The 
  9014.     PPP/IPCP extension for 32 bit Alignment of IP datagrams provides a 
  9015.     method to negotiate and align IP datagrams on a 32 bit boundary. This 
  9016.     document describes the use of the Internet Protocol Control Protocol 
  9017.     (IPCP) [2] option and the PPP framing that is required for alignment of
  9018.     all IP datagrams.                                                      
  9019.  
  9020.   "Analysis of Services and Interfaces used when Interworking Between the 
  9021.   Internet and the Intelligent Network (I.N.)", R. Scholl, 07/03/1997, 
  9022.   <draft-conroy-interfaces-in-net-00.txt>                                  
  9023.  
  9024.     The plethora of networks comprising the Internet have been getting 
  9025.     bigger and faster in the past at a tremendous rate. In the future, to 
  9026.     address all of the current and future pervasive services, the Internet 
  9027.     will also have to get better, i.e. it will need more intelligence 
  9028.     created by clever software deployed throughout the network.            
  9029.     This Internet Draft advances the discussion on the issues involved in 
  9030.     interconnecting the Internet and Public Switched Telephone Networks 
  9031.     (PSTNs), focusing on potential interfaces between Internet-based 
  9032.     devices and Intelligent Network (I.N.) devices.                        
  9033.     Services based on the interplay of PSTN / I.N. and the Internet are 
  9034.     discussed and classified, and an outline of a protocol architecture for
  9035.     the interface between the Internet and the Intelligent Network is 
  9036.     given.                                                                 
  9037.  
  9038.   "Advise on the implementation of In-Reply-To, References and Supersedes 
  9039.   e-mail and netnews headers", J. Palme, 07/07/1997, 
  9040.   <draft-palme-newfields-info-00.txt>                                      
  9041.  
  9042.     Separate Internets standards documents define the e-mail headers 
  9043.     In-Reply-To, References, Supersedes and Expires. This document, which 
  9044.     is an informational RFC, gives some advise on the implementation of 
  9045.     these features.                                                        
  9046.  
  9047.   "Transaction Internet Protocol - Requirements and Supplemental 
  9048.   Information", Jim Lyon, J. Klein, Keith Evans, 10/21/1997, 
  9049.   <draft-evans-tip-functions-02.txt>                                       
  9050.  
  9051.        This document describes the purpose (usage scenarios), and
  9052.        requirements for the Transaction Internet Protocol [1]. It is
  9053.        intended to help qualify the necessary features and functions of
  9054.        the protocol. It also provides supplemental information to aid
  9055.        understanding and facilitate implementation of the TIP protocol.    
  9056.  
  9057.   "Telnet Remote Serial Port (RSP) Option", R. Barnes, M. Bennett, 
  9058.   09/10/1997, <draft-barnes-telnet-rsp-opt-01.txt>                         
  9059.  
  9060.     Many (if not all) terminal servers support the ability to set up a
  9061.        telnet listener on a serial port.  This allows a connection to a 
  9062.     port
  9063.        to be made via the network, however only (two way) data can be
  9064.        transferred between the client and the port.
  9065.      
  9066.        By using the Remote Serial Port (RSP) telnet option, the client is
  9067.        able to control non-data aspects of the port such as baud rate and
  9068.        modem signals.  This is especially important where the port is
  9069.        attached to a modem and modem signals are required to hangup the
  9070.        modem.
  9071.      
  9072.        This document defines a simple protocol which allows terminal 
  9073.     servers
  9074.        (and other systems which provide access to serial ports via a 
  9075.     network
  9076.        connection) to provide access to these features.                    
  9077.  
  9078.   "Cache Array Routing Protocol v1.1", K. Ross, V. Valloppillil, 
  9079.   10/20/1997, <draft-vinod-carp-v1-02.txt>                                 
  9080.  
  9081.     The Cache Array Routing Protocol describes a distributed caching 
  9082.     protocol based on
  9083.     
  9084.      1) a known membership list of loosely coupled proxies and
  9085.      2) a hash function for dividing URL space among those proxies
  9086.     
  9087.     The Proxy Array Membership Table is defined as a plain ASCII text file 
  9088.     retrieved from an Array Configuration URL.  This document does NOT 
  9089.     describe how this table is constructed, merely the format of the fields
  9090.     used by agents implementing.                                           
  9091.  
  9092.   "Key Exchange Delegation Record for the DNS", Ran Atkinson, 07/22/1997, 
  9093.   <draft-rfced-info-atkinson-01.txt>                                       
  9094.  
  9095.     This note describes a mechanism whereby authorisation for one node to 
  9096.     act as key exchanger for a second node is delegated and made available 
  9097.     via the Secure DNS.  This mechanism is intended to be used only with 
  9098.     the Secure DNS.  It can be used with several security services.  For 
  9099.     example, a system seeking to use IP Security  [Atk95a, Atk95b, Atk95c] 
  9100.     to protect IP packets for a given destination can use this mechanism to
  9101.     determine the set of authorised remote key exchanger systems for that 
  9102.     destination.                                                           
  9103.  
  9104.   "The Compressed Payload Header", M. Thomas, 07/10/1997, 
  9105.   <draft-thomas-ippcp-compression-00.txt>                                  
  9106.  
  9107.     This doucment defines the Compressed Payload Header.  The Compressed 
  9108.     Payload Header encapsulates payloads (TCP header and data for instance)
  9109.     which have been compressed for traversal of the network.  The 
  9110.     Compressed Payload Header is generally used in conjunction with the IP 
  9111.     Security Headers.                                                      
  9112.  
  9113.   "IPSOFACTO: IP Switching Over Fast ATM Cell Transport", A. Acharya, 
  9114.   07/11/1997, <draft-acharya-ipsw-fast-cell-00.txt>                        
  9115.  
  9116.     This document describes a method for mapping IP flows to ATM switches. 
  9117.     No signaling is necessary to setup a path through ATM switches. Switch 
  9118.     controllers run a IP routing protocol and execute IP forwarding. The 
  9119.     Ipsofacto component is responsible for mapping a IP flow to a switched 
  9120.     path. The focus of this document is primarily on switching IP 
  9121.     multicast. Mechanisms for switching unicast flows are also described.  
  9122.  
  9123.   "Internet Technology for Integration of Carrier Network Management (TMN) 
  9124.   and Enterprise Network Management", G. Bogler, 07/11/1997, 
  9125.   <draft-bogler-tmn-internet-00.txt>                                       
  9126.  
  9127.     The complexity of telecommunication networks, i.e. enterprise and 
  9128.     carrier networks, has grown over the last two decades. Management of 
  9129.     carrier networks and enterprise networks has followed different 
  9130.     paradigms up to now:                                                   
  9131.     - In carrier networks the Telecommunications Management Network (TMN) 
  9132.     as created by ITU-T in the early 1980s is still being propagated.      
  9133.     - In enterprise networks the SNMP based approach is widely accepted.   
  9134.     The borders between public (carrier) and private (enterprise) networks 
  9135.     are becoming increasingly transparent, a distinction between both types
  9136.     of networks may soon be irrelevant from a network management point of 
  9137.     view.                                                                  
  9138.  
  9139.   "Key Management for Multicast: Issues and Architectures", D. Wallner, E. 
  9140.   Harder, R. Agee, 07/11/1997, <draft-wallner-key-arch-00.txt>             
  9141.  
  9142.     This report contains a discussion of the difficult problem of key 
  9143.     management for multicast communication sessions.  It focuses on two 
  9144.     main areas of concern with respect to key management, which are, 
  9145.     initializing the multicast group with a common net key and rekeying the
  9146.     multicast group.  A rekey may be necessary upon the compromise of a 
  9147.     user or for other reasons (e.g., periodic rekey).  In particular, this 
  9148.     report identifies a technique which allows for secure compromise 
  9149.     recovery, while also being robust against collusion of excluded users. 
  9150.     This is one important feature of multicast key management which has not
  9151.     been addressed in detail by most other multicast key management 
  9152.     proposals [1,2,4].  The benefits of this proposed technique are that it
  9153.     minimizes the number of transmissions required to rekey the multicast 
  9154.     group and it imposes minimal storage requirements on the multicast 
  9155.     group.                                                                 
  9156.  
  9157.   "The Site Installation Handbook", J. Walker, 07/11/1997, 
  9158.   <draft-rfced-info-walker-00.txt>                                         
  9159.  
  9160.     This memo is a first attempt at providing guidance on how to deal with 
  9161.     the perplexity of new LAN and WAN site installs.  Experienced and less 
  9162.     experienced network engineers often do each installation blindly 
  9163.     without any form or fashion.  This document is an attempt to document 
  9164.     specific install issues, practices and procedures.  It is also intended
  9165.     to be a future installation reference handbook.  Please email me with 
  9166.     any comments or additional items that may have been overlooked.  
  9167.     Hopefully you will see this as a starting point to collect data for the
  9168.     site installation that you are completing.                             
  9169.  
  9170.   "HTTP/1.1 Message Digest Attribute Request", Ari Luotonen, 07/14/1997, 
  9171.   <draft-lawrence-digest-request-00.txt>                                   
  9172.  
  9173.     This memo describes a security weakness in the current Proposed 
  9174.     Standard for HTTP Digest Access Authentication, and proposes a change 
  9175.     to that scheme to correct the deficiency.  The problem is that there is
  9176.     no mechanism for either party to indicate a requirement that messages 
  9177.     be sent with an authentication digest.                                 
  9178.  
  9179.   "IP Multicast over ATM MLIS using ATM Multicast Routers", N. Ishikawa, 
  9180.   07/15/1997, <draft-ishikawa-ion-mcatm-mlis-00.txt>                       
  9181.  
  9182.     This memo describes the specification for IP multicast over ATM MLIS 
  9183.     using ATM multicast routers. This memo specifies the protocol for 
  9184.     providing the functions of IGMP [1] over the ATM networks. This is the 
  9185.     simplest approach among various proposals for IP multicast over the ATM
  9186.     networks including MARS [2], and it is easy to implement this 
  9187.     specification compared with other proposals.                           
  9188.  
  9189.   "IP Multicast Routing over ATM", N. Ishikawa, 07/15/1997, 
  9190.   <draft-ishikawa-ion-mcatm-routing-00.txt>                                
  9191.  
  9192.     This memo describes the specification for IP multicast routing over 
  9193.     ATM. This memo specifies the architecture and the protocol for scalable
  9194.     IP multicast routing over ATM, based on the shared tree architecture. 
  9195.     Multicast shortcuts over ATM are possible in an efficient and scalable 
  9196.     manner. The same messages as specified for IP multicasting over ATM 
  9197.     MLIS [1] are applied for IP multicast routing over ATM, with some 
  9198.     extensions.                                                            
  9199.  
  9200.   "Open Software Distribution Methods", R. Meier, 07/16/1997, 
  9201.   <draft-meier-instructions-00.txt>                                        
  9202.  
  9203.     This document provides a common framework for the coordination of 
  9204.     standards employed in software distribution.  Software distribution is 
  9205.     divided into consecutive steps that encapsulate the procedures 
  9206.     necessary to ensure interoperability.                                  
  9207.  
  9208.   "Path MTU discovery in the presence of security gateways", M. Richardson,
  9209.   07/16/1997, <draft-richardson-ipsec-pmtu-discov-00.txt>                  
  9210.  
  9211.     This document describes the problem of getting accurate Path MTU 
  9212.     information in the presence of untrusted routers. Typical Path MTU 
  9213.     discovery is done by sending packets with the don't fragment bit set, 
  9214.     and listening for ICMP messages from routers that want to fragment the 
  9215.     packets.  Unfortunately, these messages could be forged, and IPsec 
  9216.     based security system(s) can not pass make direct use of these 
  9217.     messages. An alternate, backwards compatible algorithm is suggested.   
  9218.  
  9219.   "Why traceroute can not work through IPsec gateways", M. Richardson, 
  9220.   07/16/1997, <draft-richardson-ipsec-icmp-filter-00.txt>                  
  9221.  
  9222.     This document describes the problem of doing diagnostics through IPsec 
  9223.     gateways (VPNs). If the gateways implement their policies to the 
  9224.     letter, then diagnostics are not possible.                             
  9225.  
  9226.   "NNTP Generic Data Extensions", B. Hernacki, 07/17/1997, 
  9227.   <draft-hernacki-nntpget-00.txt>                                          
  9228.  
  9229.     This document describes a set of enhancements to the Network News  
  9230.     Transport  Protocol  [NNTP-977]  that  provide  a generic mechanism by 
  9231.     which clients and servers can exchange configuration information. It 
  9232.     was  originally  designed as a method by which an NNTP client could 
  9233.     request URLs from the server in order to access out-of-band 
  9234.     information.  It  is  not however  limited  to  URLs and may be used to
  9235.     communicate such things as language settings, client prefences, 
  9236.     formatting  information,  etc.  The protocol  additions are designed in
  9237.     a manner which allows the client and server to exchange key/data pairs 
  9238.     of arbitrary text strings.                                             
  9239.  
  9240.   "Capabilities Negotiation with BGP-4", J. Scudder, R. Chandra, 
  9241.   07/17/1997, <draft-chandra-bgp4-cap-neg-00.txt>                          
  9242.  
  9243.     Currently BGP-4 [BGP-4] requires that when a BGP speaker receives an 
  9244.     OPEN message with one or more unrecognized Optional Parameters, the 
  9245.     speaker must terminate BGP peering. This complicates introduction of 
  9246.     new capabilities in BGP.                                               
  9247.     This document defines new Optional Parameter, called Capabilities, that
  9248.     is expected to facilitate introduction of new capabilities in BGP by 
  9249.     providing graceful capability negotiation.                             
  9250.     The proposed parameter is backward compatible - a router that supports 
  9251.     the parameter can maintain BGP peering with a router that doesn't 
  9252.     support the parameter.                                                 
  9253.  
  9254.   "LDAP Object Class for Application Users", B. Greenblatt, 07/21/1997, 
  9255.   <draft-greenblatt-ldap-applusers-00.txt>                                 
  9256.  
  9257.     In working with various directory enabled applications and services, it
  9258.     has been noticed that several of them presume the existence of an 
  9259.     auxiliary object class with no attributes that is used to detect 
  9260.     'their' users.  For example, the foo application service will use the 
  9261.     fooUser object class, and attach this object class to all of its user 
  9262.     objects in the directory in order that it may later on easily detect 
  9263.     'its' users, by virtue of the fact that those users are members of the 
  9264.     fooUser object class.  This fooUser object class is a subclass of top 
  9265.     with no additional attributes.  This specification intends to head off 
  9266.     the day when a user would get one of these applicationUser object class
  9267.     things attached to its directory object for each application that it 
  9268.     uses.  This would mean that that object's object class attribute would 
  9269.     eventually have dozens of values, which would in turn lessen the value 
  9270.     of this attribute.                                                     
  9271.  
  9272.   "Guidelines for Next Hop Client (NHC) developers", L. Winkler, R. 
  9273.   Carlson, 07/23/1997, <draft-carlson-nhrp-00.txt>                         
  9274.  
  9275.     This document provides guidelines for developers of ATM attached host 
  9276.     implementations of the Next Hop Resolution Protocol Client (NHC) 
  9277.     protocol.  The intent is to define the interaction between the NHC code
  9278.     and the TCP/IP protocol stack of the local operating system.  The NHC 
  9279.     is capable of sending NHRP requests to a Next Hop Resolution Protocol 
  9280.     Server (NHS) to resolve both inter and intra LIS addresses.  The NHS 
  9281.     reply may be positive (ACK) indicating a short-cut path is available or
  9282.     negative (NAK) indicating that a shortcut is not available and the 
  9283.     routed path must be used.  The NHC must cache (maintain state) for both
  9284.     the ACK and NAK replies in order to use the correct short-cut or routed
  9285.     path.  The NAK reply must be cached to avoid making repeated requests 
  9286.     to the NHS when the routed path is being used.                         
  9287.  
  9288.   "IMSS: IP Multicast Shortcut Service", T. Anker, D. Breitgand, D. Dolev, 
  9289.   Z. Levy, 07/23/1997, <draft-anker-congress-00.txt>                       
  9290.  
  9291.     This memo describes an IP Multicast Shortcut Service (IMSS) over a 
  9292.     large ATM cloud. The service enables cut-through routing between 
  9293.     routers serving different Logical IP Subnets (LISs). The presented 
  9294.     solution is complementary to MARS [2], adopted as the IETF standard 
  9295.     solution for IP multicast over ATM.                                    
  9296.     IMSS consists of two orthogonal components: CONnection-oriented Group 
  9297.     address RESolution Service (CONGRESS) and IP multicast SErvice for 
  9298.     Non-broadcast Access Networking TEchnology (IP-SENATE). An IP class D 
  9299.     address is resolved into a set of addresses of multicast routers that 
  9300.     should receive the multicast traffic targeted to this class D address. 
  9301.     This task is accomplished using CONGRESS. The cut-through routing 
  9302.     decisions and actual data transmission are performed by IP-SENATE.     
  9303.     IMSS preserves the classical LIS model [8]. The scope of IMSS is to 
  9304.     facilitate inter-LIS cut-through routing, while MARS provides tools for
  9305.     the intra-LIS IP multicast.                                            
  9306.  
  9307.   "Dynamic Tunneling Path Configuration for Uni-directional Link Routing", 
  9308.   A. Tosaka, H. Izumiyama, 07/23/1997, <draft-izumiyama-udlr-dtpc-00.txt>  
  9309.  
  9310.     The idea to use unidirectional link(UDL) routing without any 
  9311.     modifications of current routing protocols is described in [1], but any
  9312.     dynamic tunneling path configuration technique was not described.  This
  9313.     document describe the dynamic tunneling path configuration for UDL 
  9314.     routing.                                                               
  9315.  
  9316.   "An IP tunneling approach for Uni-directional Link routing", A. Kato, A. 
  9317.   Tosaka, H. Izumiyama, 07/23/1997, <draft-izumiyama-udlr-tunnel-00.txt>   
  9318.  
  9319.     Since digital multichannel TV broadcasting services have been started 
  9320.     in many areas, low cost digital data receivers are available. They can 
  9321.     be used for not only TV broadcasting service but also any kind of data 
  9322.     communication services.                                                
  9323.     A low cost receiver can receive high bandwidth traffic from a feed, 
  9324.     while no bandwidth from the receiver to the feed is provided.  
  9325.     Therefore the connection between the feed and the receiver is 
  9326.     unidirectional. Current routing protocols stand on a fact that any 
  9327.     links are bidirectional even if the bandwidth in each direction may be 
  9328.     different. They can not handle unidirectional links.                   
  9329.     This document defines an idea to use unidirectional links (UDLs) 
  9330.     routing without any modifications of current routing protocols.        
  9331.  
  9332.   "SOCKS V5 UDP and Multicast Extensions", D. Chouinard, 07/24/1997, 
  9333.   <draft-chouinard-aft-socksv5-mult-00.txt>                                
  9334.  
  9335.     This proposal describes extensions to the SOCKS v5 protocol [RFC-1928] 
  9336.     that make it more useful for networked-multimedia applications that use
  9337.     UDP and multicast services.  The extensions are broken into two parts: 
  9338.     Base-level UDP extensions, and Multicast UDP extensions.               
  9339.     The Base-level UDP extensions augment SOCKS V5 by addressing current 
  9340.     deficiencies in [RFC-1928] (such as supporting multihomed-SOCKS servers
  9341.     and properly supporting fragmentation) and by adding several 
  9342.     performance enhancements, including the ability to control multiple UDP
  9343.     associations over a single SOCKS TCP control connection.               
  9344.     The Multicast extensions build on the foundation provided by the 
  9345.     base-level UDP extensions, and allow a Multicast-capable SOCKS Client 
  9346.     (MSC) to send and/or receive datagrams to/from one or more multicast 
  9347.     groups through a Multicast-capable SOCKS Server (MSS). These protocol 
  9348.     extensions effectively enable the MSS to become a generic multicast 
  9349.     proxy server -- allowing it to enforce security policies relating to 
  9350.     who can send multicast traffic out, or bring multicast traffic into, an
  9351.     organization.                                                          
  9352.  
  9353.   "ESP with Cipher Block CheckSums (CBCS)", W. Simpson, 07/24/1997, 
  9354.   <draft-simpson-ipsec-cbcs-00.txt>                                        
  9355.  
  9356.     This document describes the Cipher Block Chaining mode with additional 
  9357.     single or double parallel CheckSums for integrity, used with a number 
  9358.     of Internet Encapsulating Security Payload (ESP) transforms.  This 
  9359.     version is described in terms of 64-bit block ciphers, but can be 
  9360.     expanded to other block sizes.                                         
  9361.  
  9362.   "Guidelines for Writing RFC Text on  Security Considerations", Ran 
  9363.   Atkinson, 07/25/1997, <draft-iab-secwks-sec-guidelines-00.txt>           
  9364.  
  9365.     The 'Security Considerations' section of an RFC is a mechanism via 
  9366.     which the authors/editors of an RFC communicate to the reader the 
  9367.     security issues (including threats) of the RFC topic and discuss 
  9368.     mechanisms for mitigating or eliminating those threats.  Each risk 
  9369.     reduction mechanism not documented directly in that RFC should cite 
  9370.     another RFC or document which describes the risk reduction mechanism.  
  9371.  
  9372.   "Proposal for SPKI Certificate Formats and Semantics", T. Ylonen, 
  9373.   07/25/1997, <draft-ylonen-spki-binary-00.txt>                            
  9374.  
  9375.     This document is a proposal for certificate formats and their semantics
  9376.     in SPKI.  This proposal it is not based on S-expressions.              
  9377.  
  9378.   "Synchronous IP Switching Protocol", I. Jeyasubramanian, 07/25/1997, 
  9379.   <draft-jeya-sync-ip-switch-00.txt>                                       
  9380.  
  9381.     The 'Synchronous IP Switching' protocol provides a framework for 
  9382.     synchronous communication among end stations through an ethernet 
  9383.     switch.  This proposal enhances the capability of an ethernet switch to
  9384.     forward the packets from a variety of real time applications in a 
  9385.     synchronous manner with less delay variations and consistent throughput
  9386.     by introducing the concept of 'Time Switch'.  This protocol proves its 
  9387.     importance, as more and more applications need constant delay, 
  9388.     effective bandwidth while forwarding their packets to their 
  9389.     destination.                                                           
  9390.  
  9391.   "Information Exchange to Be Supported by the Service Support Transfer 
  9392.   Protocol (SSTP)", H. Lu, M. Krishnaswamy, 07/28/1997, 
  9393.   <draft-krishna-telephone-sw-net-00.txt>                                  
  9394.  
  9395.     This Internet Draft outlines the information to be carried by the 
  9396.     Service Support Transfer Protocol (SSTP) running on top of a reliable 
  9397.     transport layer (such as TCP). The SSTP is for interconnection between 
  9398.     the Internet and the Public Switched Telephone Network (PSTN), 
  9399.     specifically, involving Web Server in the former; and Service Node (SN)
  9400.     or Service Control Point (SCP), and Service Management System (SMS) [1]
  9401.     in the latter. It is to support a combination of services provided 
  9402.     otherwise disjointly by either of the network types. Service examples 
  9403.     are those integrating the traditional telephony services on the PSTN 
  9404.     and the World Wide Web-based services on the Internet like 
  9405.     click-to-dial, click-to-fax, click-to-fax-back, and 
  9406.     voice-access-to-content.                                               
  9407.  
  9408.   "Directory Schema Listing Requirements", Chris Apple, 10/13/1997, 
  9409.   <draft-apple-schema-rqmts-list-02.txt>                                   
  9410.  
  9411.     This memo documents requirements for listing directory services
  9412.     schemas in a centrally operated, administered, and maintained
  9413.     repository. This repository will be available as a resource to
  9414.     directory protocol and service implementors to facilitate schema
  9415.     discovery.                                                             
  9416.  
  9417.   "Internet Email Subaddressing", C Newman, 07/29/1997, 
  9418.   <draft-newman-email-subaddr-00.txt>                                      
  9419.  
  9420.          It is often useful for a single user to have multiple email
  9421.          addresses which can be used to assist categorizing incoming email.
  9422.          One way of doing this is to divide the local-part of an email
  9423.          address into a primary address and a subaddress.  The primary
  9424.          address is used to route the message within the specified domain
  9425.          and the subaddress is used to route the message according to a
  9426.          particular user's wishes.
  9427.      
  9428.          This specification formalizes the de-facto standard for
  9429.          subaddressing in use today and includes advice and requirements 
  9430.     for
  9431.          final delivery agents, MUAs and mail list servers which wish to
  9432.          support subaddressing.
  9433.                                                                            
  9434.  
  9435.   "RTP Payload Format for BT.656-3 Encoding", Dermot Tynan, 07/30/1997, 
  9436.   <draft-tynan-rtp-bt656-00.txt>                                           
  9437.  
  9438.     This document specifies the RTP payload format for
  9439.               encapsulating ITU Recommendation BT.656-3 video streams in 
  9440.     the
  9441.               Real-Time Transport Protocol (RTP).  Each RTP packet contains
  9442.               one scan line as defined by ITU Recommendation BT.601-5, and
  9443.               includes decoding and positioning information.               
  9444.  
  9445.   "End-to-End Traffic Management Issues in IP/ATM Internetworks", Nanying 
  9446.   Yin, Shantigram Jagannath, 07/30/1997, <draft-jagan-e2e-traf-mgmt-00.txt>
  9447.  
  9448.     This document addresses the end-to-end traffic management issues in
  9449.        IP/ATM internetworks. In the internetwork environment, the ATM
  9450.        control mechanisms (e.g., Available Bit Rate (ABR) and UBR with 
  9451.     Early
  9452.        Packet Discard (EPD)) are applicable to the ATM subnetwork, while 
  9453.     the
  9454.        TCP flow control extends from end to end. We investigated the end to
  9455.        end performance in terms of TCP throughput and file transfer delay 
  9456.     in
  9457.        cases using ABR and UBR in the ATM subnetwork. In this document, we
  9458.        also discuss the issue of trade-off between the buffer requirements
  9459.        at the ATM edge device (e.g., Ethernet-ATM switch, ATM router
  9460.        interface) versus ATM switches inside the ATM network.
  9461.      
  9462.        Our simulation results show that in certain scenarios (e.g., with
  9463.        limited edge device buffer memory) UBR with EPD may perform
  9464.        comparably to ABR or even outperform ABR. We show that it is not
  9465.        sufficient to have a lossless ATM subnetwork from the end-to-end
  9466.        performance point of view. The results illustrate the necessity for
  9467.        an edge device congestion handling mechanism that can couple the ABR
  9468.        and TCP feedback control loops.  We present an algorithm that makes
  9469.        use of the ABR feedback information and edge device congestion state
  9470.        to make packet dropping decisions at the edge of the ATM network.
  9471.        Using the algorithm at the edge device, the end-to-end performance 
  9472.     in
  9473.        throughput and delay are improved while using ABR as the ATM
  9474.        subnetwork technology and with small buffers in the edge device.    
  9475.  
  9476.   "ACK Spacing for High Delay-Bandwidth Paths with Insufficient Buffering",
  9477.   C. Partridge, 07/30/1997, <draft-partridge-e2e-ackspacing-00.txt>        
  9478.  
  9479.        Suppose you want TCP implementations to be able to fill a 155 Mb/s
  9480.        path.  Further suppose that the path includes a satellite in a
  9481.        geosynchronous orbit, so the round trip delay through the path is at
  9482.        least 500 ms, and the delay-bandwidth product is 9.7 megabytes or
  9483.        more.
  9484.      
  9485.        If we further assume the TCP implementations support TCP Large
  9486.        Windows and PAWS (many do), so they can manage 9.7 MB TCP window,
  9487.        then we can be sure the TCP will eventually start sending at full
  9488.        path rate (unless the satellite channel is very lossy).  But it may
  9489.        take a long time to get the TCP up to full speed.                   
  9490.  
  9491.   "HTTP X-Connfrom header", J Mogul, P. Leach, Larry Harada, Hudson 
  9492.   Hendren, 09/15/1997, <draft-harada-http-xconnfrom-01.txt>                
  9493.  
  9494.             HTTP/1.1 defines a Connection header, allowing 'the sender
  9495.             to specify options that are desired for that particular
  9496.             connection and MUST NOT be communicated by proxies over
  9497.             further connections.'  Because HTTP/1.0 proxies would
  9498.             normally forward the Connection header without obeying its
  9499.             specification, a Connection header received in an HTTP/1.0
  9500.             message must normally be treated as if it had been
  9501.             forwarded in error.  This document defines an X-Connfrom
  9502.             header that identifies the sending host, and so is safe to
  9503.             use in HTTP/1.0 messages.  This might be useful in
  9504.             experimenting with HTTP/1.0 implementations of applications
  9505.             of the HTTP/1.1 Connection mechanism.                          
  9506.  
  9507.   "Scalability Issues in Label Switching over ATM", G. Armitage, Zheng 
  9508.   Wang, 07/30/1997, <draft-wang-mpls-scaling-atm-00.txt>                   
  9509.  
  9510.        The scalability of label switching over ATM is one of fundamental
  9511.        issues in MPLS that has not been fully understood. Whether or not 
  9512.     one
  9513.        should assume stream merging in ATM is a major design decision that
  9514.        has many implications to MPLS protocols and ATM hardware design.    
  9515.  
  9516.   "Handling Internationalized Query Components in URLs", M. Duerst, 
  9517.   07/30/1997, <draft-duerst-query-i18n-00.txt>                             
  9518.  
  9519.     HTTP and HTML provide the facility to query the user and return the
  9520.     results. This is usually done in the query component of an URL. This
  9521.     mechanisms works with full satisfaction for characters of the us-
  9522.     ascii repertoire. Due to the lack of an agreed encoding for other
  9523.     characters, the situation is much less satisfactory for characters
  9524.     outside the us-ascii repertoire.                                       
  9525.  
  9526.   "Normalization of Internationalized Identifiers", M. Duerst, 07/30/1997, 
  9527.   <draft-duerst-i18n-norm-00.txt>                                          
  9528.  
  9529.     The Universal Character Set (UCS) makes it possible to extend the
  9530.     repertoire of characters used in non-local identifiers beyond US-
  9531.     ASCII. The UCS contains a large overall number of characters, many
  9532.     codepoints for backwards compatibility, and various mechanisms to
  9533.     cope with the features of the writing systems of the world.  All this
  9534.     together can lead to ambiguities in representation.  Such ambiguities
  9535.     are not a problem when representing running text.  Therefore existing
  9536.     standards have only defined equivalences.  For the use in identi-
  9537.     fiers, which are compared using their binary representation, this is
  9538.     not sufficient.  This document defines a normalization algorithm and
  9539.     gives usage guidelines to avoid such ambiguities.                      
  9540.  
  9541.   "DHCP Server Verification by Client Via DNSSEC", O. Gudmundsson, Robert 
  9542.   Watson, 07/30/1997, <draft-watson-dhc-serv-verify-00.txt>                
  9543.  
  9544.     The document defines a mechanism to allow a DHCP client to verify
  9545.        the authenticity of a DHCP server configuration offer using
  9546.        DNSSEC.   Currently DHCP clients have no way to assess which of
  9547.        DHCP OFFERS are from valid DHCP servers, and which are not.
  9548.        Malicious DHCP servers can cause various network problems for
  9549.        unsuspecting clients. 
  9550.     
  9551.        In order to support DHCP server authorization a new DNS Resource 
  9552.        Record type (ALLOC) is added. Using the ALLOC record in combination 
  9553.     with the servers KEY record the client can authoritatively assess if
  9554.        the server is authorized.                                           
  9555.  
  9556.   "Transmission of IPv6 Packets over Frame Relay", A. Conta, Martin 
  9557.   Mueller, 07/30/1997, <draft-conta-ipv6-trans-fr-00.txt>                  
  9558.  
  9559.     This memo describes the  transmission  of  IPv6  packets  over  
  9560.     Frame Relay,  the  IPv6  Frame  Relay interface token, the IPv6 Frame 
  9561.     Relay link local addresses, the IPv6 Frame  Relay  link  layer  
  9562.     Information formatting for Neighbor Discovery.                         
  9563.  
  9564.   "Conversion of MIMEDIR content into XML", A. Hopmann, 07/30/1997, 
  9565.   <draft-hopmann-mimedirxml-00.txt>                                        
  9566.  
  9567.     This document specifies how to translate information which is
  9568.       represented in the MIMEDIR format into a representation of the
  9569.       identical information using the XML syntax. Using this specification,
  9570.       applications which have been designed to understand MIMEDIR formatted
  9571.       data should be able to interoperate using XML representations of the
  9572.       same schemas.                                                        
  9573.  
  9574.   "IPv6 Inverse Neighbor Discovery for IPv6 and IPv4 Tunnels", A. Conta, 
  9575.   07/30/1997, <draft-conta-ipv6-inv-nd-tun-00.txt>                         
  9576.  
  9577.     This memo describes an extension mechanism to the IPv6 Neighbor  
  9578.     Discovery and IPv6 Inverse Neighbor Discovery [IND] that applies to 
  9579.     IPv6
  9580.     and IPv4 tunnels.  The mechanism can be used to advertise the 
  9581.     parameters of a tunnel to its exit point node, and to create a reverse 
  9582.     tunnel path between the exit point and entry point nodes of a  
  9583.     unidirectional  tunnel.   If  such a bidirectional tunnel already 
  9584.     exists, the
  9585.     mechanism can be used to learn the IPv6 address of the tunnel 
  9586.     pseudointerface  of the exit-point node, as well as the reverse tunnel 
  9587.     path parameters.                                                       
  9588.  
  9589.   "Error Record (ERR) for DNS", O. Gudmundsson, Robert Watson, 07/30/1997, 
  9590.   <draft-watson-dns-error-00.txt>                                          
  9591.  
  9592.     The DNS protocol defines a 4-bit RCODE field in the header of the DNS 
  9593.     envelope.  This field is used to indicate the completion status of 
  9594.     requests.  Defined values exist to describe successful completion as 
  9595.     well as a variety of error conditions that could result from DNS server
  9596.     operations.  As DNS has been expanded to perform additional functions,
  9597.     the number of possible error conditions has increased significantly, 
  9598.     and the field no longer has space for new error codes to be added.  To 
  9599.     address this problem, a new RR type is defined.  The Error Record 
  9600.     contains a machine-readable extended error value, as well as an 
  9601.     optional 
  9602.     human-readable ASCII text string.  Additionally, it contains a
  9603.     domain-name source field to identify the entity generating the error 
  9604.     condition.This RR may also be used in non-error conditions to provide 
  9605.     extended information about server responses, such security information 
  9606.     on specific records in the response.                                   
  9607.  
  9608.   "A Stream Cipher Encryption Algorithm 'Arcfour'", Rodney Thayer, Kalle 
  9609.   Kaukonen, 07/30/1997, <draft-kaukonen-cipher-arcfour-01.txt>             
  9610.  
  9611.     This document describes an algorithm here called Arcfour that
  9612.     is believed to be fully interoperable with the RC4 algoritm.
  9613.     RC4 is trademark of RSA Data Security, Inc.  There is a need
  9614.     in the Internet community for an encryption algorithm that
  9615.     provides interoperable operation with existing deployed
  9616.     commercial cryptographic applications.  This interoperability
  9617.     will allow for a smoother transition to protocols that have
  9618.     been developed through the IETF standards process.                     
  9619.  
  9620.   "Universal Forms Description Language Specification Version 3.2",, 
  9621.   07/31/1997, <draft-gordon-ufdl-spec-00.txt>                              
  9622.  
  9623.     The Universal Forms Description Language (UFDL) describes complex
  9624.         business forms for use over the Internet. The objective of the UFDL
  9625.         is to enable the creation of cross-platform Internet business forms
  9626.         that (1) contain both the complex logic and precise layout that
  9627.         administrators require, (2) are simple to maintain and distribute,
  9628.         and (3) integrate easily with existing business systems. As more
  9629.         and more business is done over the Internet, the need for a form
  9630.         description language that incorporates these features grows. HTML
  9631.         is designed for Internet pages, and is severely limited as a form
  9632.         language. This document specifies the vocabulary, syntax, and
  9633.         meaning of the UFDL.                                               
  9634.  
  9635.   "When TCP Starts Up With Four Packets Into Only Three Buffers", C. 
  9636.   Partridge, Timothy Shepard, 08/01/1997, 
  9637.   <draft-shepard-tcp-4-packets-3-buff-00.txt>                              
  9638.  
  9639.     Sally Floyd has proposed that TCPs start their initial slow start by
  9640.        sending as many as four packets (instead of the usual one packet) as
  9641.        a means of getting TCP up-to-speed faster.  (Slow starts instigated
  9642.        due to timeouts would still start with just one packet.)  Starting
  9643.        with more than one packet might reduce the start-up latency over
  9644.        long-fat pipes by two round-trip times.  This proposal is documented
  9645.        further in [1] and in [2] and we assume the reader is familiar with
  9646.        the details of this proposal.
  9647.      
  9648.        On the end2end-interest mailing list, concern was raised that in the
  9649.        (allegedly common) case where a slow modem is served by a router
  9650.        which only allocates three buffers per modem (one buffer being
  9651.         transmitted while two packets are waiting), that starting with four
  9652.        packets would not be good because the fourth packet is sure to be
  9653.        dropped.
  9654.      
  9655.        Vern Paxson replied with the comment (among other things) that the
  9656.        four-packet start is no worse than what happens after two round trip
  9657.        times in normal slow start, hence no new problem is introduced by
  9658.        starting with as many as four packets.   If there is a problem with 
  9659.     a
  9660.        four-packet start, then the problem already exists in a normal slow-
  9661.        start startup after two round trip times when the slow-start
  9662.        algorithm will release into the net four closely spaced packets.
  9663.      
  9664.        This memo is to document that in the case of a 9600 bps modem at the
  9665.        edges of a fast Internet where there are only 3 buffers before the
  9666.        modem (and the fourth packet of a four-packet start will surely be
  9667.        dropped), no significant degradation in performance is experienced
  9668.        with a four-packet start when compared with a normal slow start
  9669.        (which starts with one packet).                                     
  9670.  
  9671.   "Uniform Resource Locators (URL): DNS URL Naming Scheme", Y. Goland, 
  9672.   07/31/1997, <draft-goland-url-dns-00.txt>                                
  9673.  
  9674.     This document proposes mapping DNS names into the URL scheme space for
  9675.     the purpose of preventing namespace collisions amongst URL schemes
  9676.     whose syntax and functionality are not appropriate for standardization.
  9677.  
  9678.   "Universal Forms Description Language Specification Version 3.2", Bill 
  9679.   Manning, 07/31/1997, <draft-ietf-ufdl-spec-00.txt>                       
  9680.  
  9681.         The Universal Forms Description Language (UFDL) describes complex
  9682.         business forms for use over the Internet. The objective of the UFDL
  9683.         is to enable the creation of cross-platform Internet business forms
  9684.         that (1) contain both the complex logic and precise layout that
  9685.         administrators require, (2) are simple to maintain and distribute,
  9686.         and (3) integrate easily with existing business systems. As more
  9687.         and more business is done over the Internet, the need for a form
  9688.         description language that incorporates these features grows. HTML
  9689.         is designed for Internet pages, and is severely limited as a form
  9690.         language. This document specifies the vocabulary, syntax, and
  9691.         meaning of the UFDL.                                               
  9692.  
  9693.   "DHCP Option for IPv6 Transitions", D. Harrington, 08/01/1997, 
  9694.   <draft-harrington-ngtrans-dhcp-option-00.txt>                            
  9695.  
  9696.     This draft introduces a proposed DHCP option which could be helpful
  9697.     in establishing connectivity between isolated IPv6 hosts and routers
  9698.     in an IPv4 network.  This work is introduced to the NGTrans Working
  9699.     Group initially, and will also be reviewed in the DHCP Working
  9700.     Group.
  9701.                                                                            
  9702.  
  9703.   "DHCP Options for Locating LDAP Servers", L. Howard, 08/01/1997, 
  9704.   <draft-hedstrom-dhc-ldap-00.txt>                                         
  9705.  
  9706.        This document defines a new DHCP option for delivering configuration
  9707.        information to LDAP (Lightweight Directory Access Protocol) clients.
  9708.        The information returned is represented as LDAP URLs, as specified 
  9709.     in
  9710.        the LDAPv3 URL draft[1].
  9711.      
  9712.        The DHCP client may use the URLs returned by the DHCP server to
  9713.        locate an LDAP server for the client's network. The URL may include
  9714.        the TCP port of the LDAP server, and the distinguished name which
  9715.        identifies the base object for searching.
  9716.      
  9717.                                                                            
  9718.  
  9719.   "IP Encapsulating Security Payload (ESP) for Implementors", W. Simpson, 
  9720.   08/01/1997, <draft-simpson-esp-v2-00.txt>                                
  9721.  
  9722.     This document describes a confidentiality mechanism for IP datagrams.
  9723.     Payload headers are encapsulated within an opaque envelope.  Under
  9724.     some circumstances, authentication and integrity are optionally 
  9725.     provided for IP datagrams.                                             
  9726.  
  9727.   "Security issues for ION protocols", G. Armitage, 10/13/1997, 
  9728.   <draft-armitage-ion-security-01.txt>                                     
  9729.  
  9730.        This document aims to assist people attempting to understand the
  9731.        security limitations of existing ION working group protocols RFC 
  9732.     2022
  9733.        (MARS), and RFC xxxx (NHRP). As RFC 2022 and RFC xxxx share their
  9734.        basic control message protocol(s), this document also identifies
  9735.        common areas amenable to improvement using additional security TLVs.
  9736.  
  9737.   "Assignment of Status Codes for HTTP and HTTP-Derived Protocols", H. 
  9738.   Schulzrinne, 08/01/1997, <draft-schulzrinne-http-status-00.txt,.ps>      
  9739.  
  9740.     A number of other protocols may make use of HTTP syntax
  9741.              and facilities; this memo defines a mechanism for IANA to
  9742.              allocate status codes.                                        
  9743.  
  9744.   "Support of Shortcuts for RSVP Flows Over ATM", Lou Berger, Vijay 
  9745.   Srinivasan, 08/01/1997, <draft-guerin-issll-rsvp-shortcut-00.txt>        
  9746.  
  9747.        Support for RSVP flows across an ATM network has been defined in
  9748.        [BB97, GB97, Ber97a].  Although the use of shortcuts was mentioned 
  9749.     in
  9750.        [BB97, Sec.  3.7], and [Ber97a, Sec.  3.6] the current 
  9751.     specifications
  9752.        do not address this case in sufficient details so as to allow
  9753.        interoperable implementations.  The purpose of this document is to
  9754.        identify issues in using ATM shortcuts for RSVP flows.  For purposes
  9755.        of illustrations, the NHRP protocol [LKPC97] will be assumed as
  9756.        the mechanism used to discover shortcuts, and a possible interface
  9757.        between RSVP and NHRP will be outlined.  However, it should be noted
  9758.        that other shortcut mechanisms are possible, e.g., PAR [J96], and
  9759.        the general conclusions of this document should also hold in such
  9760.        cases.  Since the issue of shortcut discovery is significantly more
  9761.        complex in the multicast case, for which in most instances has not
  9762.        been defined, e.g., NHRP, this document is limited to the case of
  9763.        unicast flows.
  9764.                                                                            
  9765.  
  9766.   "Network Security API for Sockets", C. Metz, 08/01/1997, 
  9767.   <draft-metz-net-security-api-00.txt>                                     
  9768.  
  9769.          This  API  is  a  means for sockets applications to request 
  9770.     network
  9771.        security services from an operating system. It is  designed  to  
  9772.     move
  9773.        most  of the work and intelligence of security policy processing 
  9774.     into
  9775.        the operating system so that the burden  on  application  authors  
  9776.     is
  9777.        light enough to encourage the use of network security.
  9778.      
  9779.          It  is  documented  here  for  the benefit of others who might 
  9780.     also
  9781.        adopt and use  the  API,  thus  providing  increased  portability  
  9782.     of
  9783.        applications  that  use  network  security  services  (e.g.,  the  
  9784.     IP
  9785.        Security ESP and AH protocols).
  9786.                                                                            
  9787.  
  9788.   "Performance Issues in VC-Merge Capable MPLS Switches", Anwar Elwalid, 
  9789.   Indra Widjaja, 08/02/1997, <draft-widjaja-mpls-vc-merge-00.txt>          
  9790.  
  9791.     VC merging allows many routes to be mapped to the same VC label,
  9792.        thereby providing a scalable mapping method that can support tens of
  9793.        thousands of edge routers. VC merging requires reassembly buffers so
  9794.        that cells belonging to different packets intended for the same
  9795.        destination do not interleave with each other.  This document
  9796.        investigates the impact of VC merging on the additional buffer
  9797.        required for the reassembly buffers and other buffers.  The main
  9798.        result indicates that VC merging incurs a minimal overhead compared
  9799.        to non-VC merging in terms of additional buffering. Moreover, the
  9800.        overhead decreases as utilization increases, or as the traffic
  9801.        becomes more bursty.                                                
  9802.  
  9803.   "Transmission of IPv6 Packets over IPv6 and IPv4 Tunnels.", A. Conta, 
  9804.   08/02/1997, <draft-conta-ipv6-trans-tunnel-00.txt>                       
  9805.  
  9806.        This memo describes the transmission of IPv6 packets  over  IPv6  
  9807.     and
  9808.        IPv4 tunnels, and the IPv6 tunnel link local addresses.             
  9809.  
  9810.   "Portable Node Support Using Mobile IP Protocol", G. Malkin, P. Raison, 
  9811.   N. Kossack, 08/02/1997, <draft-malkin-pnsmip-00.txt>                     
  9812.  
  9813.     This document describes an extension to the Mobile IP protocol [1]
  9814.     which allows portable nodes to tunnel, through a Service Provider's
  9815.     network, to their home networks without the need to implement any
  9816.     special code on the portable nodes.                                    
  9817.  
  9818.   "Increasing TCP's Initial Window", C. Partridge, S. Floyd, M. Allman, 
  9819.   08/02/1997, <draft-floyd-incr-init-win-00.txt>                           
  9820.  
  9821.     This is a note to suggest changing the permitted initial window in
  9822.         TCP from 1 segment to roughly 4K bytes.  This draft considers the
  9823.         advantages and disadvantages of such a changes, as well as 
  9824.     outlining
  9825.         some experimental results that indicate the costs and benefits of
  9826.         making such a change to TCP, and pointing out remaining research
  9827.         questions.                                                         
  9828.  
  9829.   "IPv6 Neighbor Discovery Extensions for Inverse Discovery Specification",
  9830.   A. Conta, 08/04/1997, <draft-conta-ipv6-nd_ext_ind-00.txt>               
  9831.  
  9832.     This memo describes a mechanism that can be seen as an  extension  to
  9833.        the  IPv6  Neighbor  Discovery.  It  allows  a node to solicit and 
  9834.     be
  9835.        advertized an  IPv6  address  corresponding  to  a  given  
  9836.     link-layer
  9837.        address.  Because  the known parameter is the link layer address, 
  9838.     the
  9839.        mechanism is called  Inverse  Neighbor  Discovery.   It  
  9840.     specifically
  9841.        applies  to  Frame  Relay  nodes that may have a Data Link 
  9842.     Connection
  9843.        Identifier  (DLCI),  the  Frame  Relay  equivalent  of  a  
  9844.     link-layer
  9845.        address,  associated  with  an  established Permanent Virtual 
  9846.     Circuit
  9847.        (PVC), but do not know the IPv6 address of the node at the other  
  9848.     end
  9849.        of  the  circuit.   It  may also apply to other networks with 
  9850.     similar
  9851.        behavior.                                                           
  9852.  
  9853.   "An Approach to Service Allocation in the Internet", David Clark, John 
  9854.   Wroclawski, 08/04/1997, <draft-clark-diff-svc-alloc-00.txt>              
  9855.  
  9856.           This note describes the Service Allocation Profile scheme for
  9857.           differential service allocation within the Internet. The scheme 
  9858.     is
  9859.           based on a simple packet drop preference mechanism at interior
  9860.           nodes, and highly flexible service profiles at edges and inter-
  9861.           provider boundary points within the net. The service profiles
  9862.           capture a wide variety of user requirements and expectations, and
  9863.           allow different users to receive different levels of service from
  9864.           the network in a scalable and efficient manner.
  9865.     
  9866.           The note describes the basic form of the mechanism, discusses the
  9867.           range of services that users and providers can obtain by 
  9868.     employing
  9869.           it, and gives a more detailed presentation of particular
  9870.           technical, deployment, standardization, and economic issues
  9871.           related to its use.
  9872.                                                                            
  9873.  
  9874.   "IP Tunnel MIB", D. Thaler, 08/04/1997, <draft-thaler-tunnel-mib-00.txt> 
  9875.  
  9876.     This memo defines an experimental portion of the Management Information
  9877.     Base (MIB) for use with network management protocols in the Internet
  9878.     community.  In particular, it describes managed objects used for
  9879.     managing tunnels of any type in IP networks, including GRE [5,6], IP-
  9880.     in-IP [7], Minimal Encapsulation [8], L2TP [9], and PPTP [10] tunnels. 
  9881.  
  9882.   "An Internet Firewall Transparency Requirement", Ned Freed, Kevin 
  9883.   Carosso, 08/21/1997, <draft-freed-firewall-req-00.txt>                   
  9884.  
  9885.     This memo defines a basic transparency requirement for
  9886.     Internet firewalls.  While such a requirement may seem
  9887.     obvious, the fact of the matter is that firewall behavior is
  9888.     currently either unspecified or underspecified, and problems
  9889.     often arise in practice. This document is intended to be a
  9890.     necessary first step in making the behavior of firewalls more
  9891.     consistent and correct.                                                
  9892.  
  9893.   "Messages between Email and Netnews", J. Palme, 08/21/1997, 
  9894.   <draft-palme-newsmail-00.txt>                                            
  9895.  
  9896.     Messages can be transported through gateways between email and netnews.
  9897.     Combined clients for mail and netnews can submit the same message at 
  9898.     the
  9899.     same time to email and netnews. Many netnews clients can produce email
  9900.     replies to the author of netnews articles. This standard specifies how
  9901.     to handle these kinds of messages. This standard specifies three new
  9902.     email headers:                                                         
  9903.  
  9904.   "Soft State Switching A Proposal to Extend RSVP for Switching RSVP 
  9905.   Flows", A. Viswanathan, S. Blake, Vijay Srinivasan, 08/25/1997, 
  9906.   <draft-viswanathan-mpls-rsvp-00.txt>                                     
  9907.  
  9908.     This memo describes a mechanism for establishing a switched path with
  9909.        guaranteed Quality of Service for RSVP [1] flows in a MultiProtocol
  9910.        Label Switching (MPLS) environment.  It proposes an extension to the
  9911.        RSVP protocol that allows the establishment of a sequence of label
  9912.        switched hops along the hop-by-hop routed path by enabling adjacent
  9913.        nodes to exchange MPLS labels [11].  The labels may correspond to
  9914.        information that identifies a layer 2 virtual connection; for
  9915.        example, the VPI/VCI value in the case of an ATM-based
  9916.        infrastructure.                                                     
  9917.  
  9918.   "PPP for Asynchronous PAD to Synchronous X.25 access", Vimal Khanna, 
  9919.   10/03/1997, <draft-rfced-info-khana-01.txt>                              
  9920.  
  9921.     The PPP protocol allows data transfer thru asynchronous or synchronous
  9922.     connections. But the prevalent Public Switched Data Networks (PSDNs)
  9923.     support connections between asynchronous and synchronous protocols. 
  9924.     This document defines extensions to the PPP protocol to support 
  9925.     asynchronous PAD to synchronous X.25 protocols on PSDNs.               
  9926.  
  9927.   "End-to-End Throughput and Response Time Testing With HTTP User Agents 
  9928.   and the JavaScript Language", Howard Stanislevic, 08/25/1997, 
  9929.   <draft-rfced-info-stanislevic-00.txt>                                    
  9930.  
  9931.     This memo describes two simple metrics and a methodology for testing
  9932.     end-to-end one-way data throughput and two-way response time at the
  9933.     application layer utilizing HTTP [1] (web) servers and user agents
  9934.     (web browsers). Two Interactive Hypertext Transfer Test (IHTTT)
  9935.     implementations are described in detail.
  9936.                                                                            
  9937.  
  9938.   "MAPPING OF AIRLINE TRAFFIC OVER IP", Alain Robert, 08/25/1997, 
  9939.   <draft-rfced-info-robert-00.txt>                                         
  9940.  
  9941.     This memo specifies a protocol for the encapsulation of the airline
  9942.     specific protocol over IP.                                             
  9943.  
  9944.   "Network Address Translation issues with IPsec", Robert Moskowitz, 
  9945.   09/02/1997, <draft-moskowitz-ipsec-vpn-nat-00.txt>                       
  9946.  
  9947.        This document looks at a number of issues surrounding the need
  9948.        for network address translation (NAT) when IPsec is used to
  9949.        create virtual private networks (NAT).  This document only
  9950.        looks at simple VPNs.  That is VPNs consisting of a single
  9951.        IPsec tunnel as compared to VPNs consisting of chained
  9952.        and/or nested IPsec tunnels and/or transports.                      
  9953.  
  9954.   "Capabilities Exchange over SMTP", N. Joffe, Dan Wing, 08/26/1997, 
  9955.   <draft-Capabilities Exchange over SMTP-00.txt>                           
  9956.  
  9957.     This document describes an extension to SMTP [RFC821] which provides a
  9958.     mechanism for capabilities exchange so the sender knows the 
  9959.     capabilities
  9960.     of the ultimate recipient or the ESMTP server itself.                  
  9961.  
  9962.   "Capabilities Exchange over SMTP", N. Joffe, Dan Wing, 08/26/1997, 
  9963.   <draft-wing-smtp-capabilities-00.txt>                                    
  9964.  
  9965.     This document describes an extension to SMTP [RFC821] which provides a
  9966.     mechanism for capabilities exchange so the sender knows the 
  9967.     capabilities
  9968.     of the ultimate recipient or the ESMTP server itself.                  
  9969.  
  9970.   "Tunnel Set-up Protocol (TSP)", G. Montenegro, 08/26/1997, 
  9971.   <draft-montenegro-tsp-00.txt>                                            
  9972.  
  9973.        Remote access over the internet and IP mobility are currently being
  9974.        addressed as two separate problems. The L2TP specification is
  9975.        defining a protocol, or rather a tunnel control mechanism to solve
  9976.        the remote access problem. On the other hand, the Mobile IP working
  9977.        group has been solving the mobility problem. Nevertheless, the same
  9978.        solution applies to both problems, namely, tunneling.
  9979.      
  9980.        This document defines a Tunnel Set-up Protocol (TSP) that solves
  9981.        both problems using a common approach. TSP is heavily based on the
  9982.        control messages defined by Mobile IP.
  9983.     
  9984.                                                                            
  9985.  
  9986.   "Japanese Character Encoding for Internet Messages", Kenzaburo Tamaru, 
  9987.   10/08/1997, <draft-rfced-info-tamaru-01.txt>                             
  9988.  
  9989.     This memo defines an encoding scheme for the Japanese Characters,
  9990.         describes 'ISO-2022-JP', which is used in electronic mail[RFC 822],
  9991.         and network news [RFC 1036]. Also this memo provides a listing of
  9992.         the Japanese Character Set that can be used in this encoding 
  9993.     scheme.                                                                
  9994.  
  9995.   "DNS Top Level Domain Name Classification and Structure", Joseph Kim, 
  9996.   08/26/1997, <draft-kim-tld-class-00.txt>                                 
  9997.  
  9998.          This document specifies a structural organization of Internet top
  9999.          level domain names based on the International Schedule of Classes
  10000.          of Goods and Services. This structure intends to provide a
  10001.          framework for classification such that web content providers can
  10002.          differentiate their goods and services and minimize the 
  10003.     probability
  10004.          of name confusion and collision. Under each class, as specified by
  10005.          the International Schedule of Classes of Goods and Services, 
  10006.     single
  10007.          or multiple top level domain names should be specified each
  10008.          appropriately partitioning the class of goods or service into an
  10009.          appropriate sub-categorization. A method will further be described
  10010.          to incorporate additions/modifications as becomes necessary by as
  10011.          of yet unforseen future developments.
  10012.      
  10013.          This document does not address the delegation or the 
  10014.     administration
  10015.          of top level domain names which the author feels should be
  10016.          considered separately. However, the author does acknowledge that
  10017.          some form of centralized authority should be in place to properly
  10018.          control the structure to be described.
  10019.                                                                            
  10020.  
  10021.   "URLs for Telephony", Antti Vaha-Sipila, 10/21/1997, 
  10022.   <draft-antti-telephony-url-01.txt>                                       
  10023.  
  10024.     This document specifies URL (Uniform Resource Locator) schemes
  10025.         'tel', 'fax' and 'modem' for specifying the location of a terminal
  10026.         in the phone network and the connection types (modes of operation)
  10027.         that can be used to connect to that entity. This specification
  10028.         covers voice calls (normal phone calls, answering machines and
  10029.         voice messaging systems), facsimile (telefax) calls and data
  10030.         calls, both for POTS and digital/mobile subscribers.               
  10031.  
  10032.   "Protecting IMAP4 and POP3 Connections", C Newman, 08/28/1997, 
  10033.   <draft-newman-tls-imappop-00.txt>                                        
  10034.  
  10035.          The TLS protocol [TLS] (formerly known as SSL) provides a way to
  10036.          secure a connection from tampering and evesdropping.  Obviously,
  10037.          such security is desirable for IMAP [IMAP4] and POP [POP3].
  10038.          Although advanced authentication mechanisms [IMAP-AUTH, POP-AUTH]
  10039.          can provide this service with less complexity than TLS, TLS is
  10040.          useful in combination with plaintext password logins and other
  10041.          simple mechanisms as it doesn't require a site to upgrade its
  10042.          authentication database.
  10043.                                                                            
  10044.  
  10045.   "Responder-Initiated Shortcut Path Protocol (RISP)", Y. Chen, J. Ogawa, 
  10046.   08/28/1997, <draft-ogawa-responder-shortcut-path-00.txt>                 
  10047.  
  10048.          This memo describes a peer-to-peer protocol to set up shortcut
  10049.          paths in an environment where an internetworking (L3) protocol,
  10050.          such as IP, overlays a link-layer (L2) protocol such as ATM.  In
  10051.          such a network, L3 routing is the default mechanism for data
  10052.          transfer but it is also possible to set up direct L2 paths such as
  10053.          ATM VCs, that bypass L3 routing, so as to expedite the transfer of
  10054.          data.  The protocol described in this memo can be applied as an
  10055.          inter-LIS (Logical IP Subnetwork) shortcut protocol when an L2
  10056.          subnetwork is configured into multiple LISs.  It can also be used
  10057.          as an independent protocol to set up direct L2 paths.  In this 
  10058.     way,
  10059.          it operates without L2 address resolution servers and allows the
  10060.          use of conventional routers (those without address resolution
  10061.          function) in the network. Therefore, it is useful for networks 
  10062.     that
  10063.          have no available L2 address resolution service.                  
  10064.  
  10065.   "SPKI: ShrinkWrap", W. Simpson, Angelos Keromytis, 09/19/1997, 
  10066.   <draft-simpson-spki-shrinkwrap-01.txt>                                   
  10067.  
  10068.     This protocol facilitates the use of Simple Public Key Infrastructure 
  10069.     [SPKI] certificate chains with Internet Protocol Security key 
  10070.     management protocols.                                                  
  10071.  
  10072.   "Mobile Network Computing Protocol (MNCP)", David Piscitello, Lisa 
  10073.   Phifer, R. Hovey, Yangwei Wang, 08/29/1997, 
  10074.   <draft-piscitello-mncp-00.txt>                                           
  10075.  
  10076.     This memo documents an architecture and protocol for mobile network
  10077.     computing. The protocol described herein provides session control and
  10078.     reliable delivery services to accommodate mobile client access to
  10079.     internetworked applications within a 'client-agent-server'
  10080.     architecture.  Client middleware based on this architecture can operate
  10081.     over wireless data networking services such as RAM, ARDIS, CDPD, PCS
  10082.     data services and wireless local area networks.  This client middleware
  10083.     can be implemented using any standard application programming interface
  10084.     to a commercial UDP/IP stack on Hand-held PC's (HPC), personal digital
  10085.     assistants (PDA's), four-line browsers or 'smart' phones as well as
  10086.     laptop and desktop computers.                                          
  10087.  
  10088.   "Hobbes' Internet Timeline", Robert Zakon, 10/07/1997, 
  10089.   <draft-rfced-info-hobbes-01.txt>                                         
  10090.  
  10091.     This document presents a history of the Internet in timeline
  10092.          fashion, highlighting some of the key events and technologies 
  10093.     which
  10094.          helped shape the Internet as we know it today.  A growth summary
  10095.          of the Internet and some associated technologies is also included.
  10096.  
  10097.   "ElGamal Profile for X.509 Certificates", Peter Gutmann, 08/29/1997, 
  10098.   <draft-rfced-info-pgutmann-00.txt>                                       
  10099.  
  10100.     This document describes the ASN.1 encoding for an X.509 certificate
  10101.     profiled for use with the ElGamal public key cryptosystem [1].  It is
  10102.     intended to provide guidelines for those developing software that will
  10103.     be used to issue and use ElGamal certificates, and to ensure that
  10104.     ElGamal certificate and key information will be handled consistently
  10105.     throughout the public key infrastructure.                              
  10106.  
  10107.   "Reliable Multicast Transport Protocol Version 2", N. Yamanouchi, T. 
  10108.   Shiroshita, T. Sano, O. Takahashi, 08/29/1997, 
  10109.   <draft-shiroshita-rmtpv2-00.txt>                                         
  10110.  
  10111.     This draft presents the specifications of the 'Reliable Multicast
  10112.     Transport Protocol Version 2,' which is to be used for information
  10113.     delivery such as newspaper delivery and software updates.
  10114.     The protocol aims to realize the completely reliable multicast
  10115.     distribution of bulk data from a server to thousands of receivers.
  10116.     Version 2 added new functions of information access control, rate
  10117.     flow control, and suspending resume.                                   
  10118.  
  10119.   "Short Port Commands for FTP", C. Metz, 09/02/1997, 
  10120.   <draft-metz-sport-00.txt>                                                
  10121.  
  10122.          RFC  1639[Pis94]  documents  experimental long port (LPRT) and 
  10123.     long
  10124.        passive (LPSV) commands that many IP Version  6  implementations  
  10125.     are
  10126.        using  as  the  replacement  for  the  PORT  and PASV commands in 
  10127.     FTP
  10128.        [PR85]. The author believes that this is the incorrect  direction  
  10129.     to
  10130.        be  heading  and  that the replacement for PORT and PASV should 
  10131.     carry
  10132.        less information instead of more.
  10133.     
  10134.         The short port command (SPORT) and short  passive  command  (SPASV)
  10135.        are  replacements  for  the PORT and PASV commands, respectively. 
  10136.     The
  10137.        short commands only carry port numbers and do  not  carry  
  10138.     addresses.
  10139.        This  makes them usable with IPv4 and IPv6. A benefit of not 
  10140.     carrying
  10141.        addresses is that pure network address translators (NAT) do not  
  10142.     have
  10143.        to  do  a search-and-replace on the TCP stream, which is an 
  10144.     expensive
  10145.        operation. This also precludes three-way FTP, which is a rarely  
  10146.     used
  10147.        mode  of operation that leaves most existing FTP servers wide open 
  10148.     to
  10149.     the FTP Bounce Attack [Hob95].
  10150.           
  10151.          The short port and passive commands  are  implemented  in  the  
  10152.     NRL
  10153.        IPv6+IPsec   software  distribution  and  the  descendant  
  10154.     inet6-apps distribution.                                               
  10155.  
  10156.   "P_Mul:  An Application Protocol for the Transfer of Messages over 
  10157.   Multicast Subnetworks and under EMCON Restrictions", Ken Copeland, 
  10158.   09/03/1997, <draft-riechmann-multicast-mail-00.txt>                      
  10159.  
  10160.        P_Mul is a proposal for an application protocol for the transfer of
  10161.        messages using a connectionless transport protocol. The objectives 
  10162.     of
  10163.        this protocol are first to take advantage of the bandwidth saving
  10164.        feature of using the multicast service as supported by modern
  10165.        computer networks and second to allow message transfer under EMCON
  10166.        conditions. EMCON (Emission Control) means that, although receiving
  10167.        nodes are able to receive messages, they are not able to acknowledge
  10168.        the receipt of messages.
  10169.           
  10170.        The protocol described below has already been applied to the 
  10171.     transfer
  10172.        of messages between X.400 Message Transfer Agents (MTA). But it is
  10173.        not only restricted to this application and can easily be applied to
  10174.        the transfer of RFC822 messages.                                    
  10175.  
  10176.   "Test Cases for HMAC-RIPEMD160 and HMAC-RIPEMD128", Justin Kapp, 
  10177.   09/03/1997, <draft-kapp-test-cases-00.txt>                               
  10178.  
  10179.        This document provides two sets of test cases for HMAC-RIPEMD160 and
  10180.        HMAC-RIPEMD128, respectively. HMAC-RIPEMD160 and HMAC-RIPEMD128 are
  10181.        two constructs of the HMAC [HMAC] message authentication function
  10182.        using the RIPEMD-160 and RIPEMD-128 [RIPE] hash functions. The test
  10183.        cases and results provided in this document are meant to be used as 
  10184.     a
  10185.        conformance test for HMAC-RIPEMD160 and HMAC-RIPEMD128
  10186.        implementations.                                                    
  10187.  
  10188.   "IMAP4 Implementation Recommendations", B. Leiba, 10/22/1997, 
  10189.   <draft-leiba-imap-implement-guide-03.txt>                                
  10190.  
  10191.        The IMAP4 specification [RFC-2060] describes a rich protocol for use
  10192.        in building clients and servers for storage, retrieval, and
  10193.        manipulation of electronic mail.  Because the protocol is so rich 
  10194.     and
  10195.        has so many implementation choices, there are often trade-offs that
  10196.        must be made and issues that must be considered when designing such
  10197.        clients and servers.  This document attempts to outline these issues
  10198.        and to make recommendations in order to make the end products as
  10199.        interoperable as possible.                                          
  10200.  
  10201.   "Labels for MPLS over LAN Media", Hiroshi Esaki, W. Pace, A. Ghanwani, 
  10202.   Shigeo Matsuzawa, Dick Bussiere, 09/09/1997, 
  10203.   <draft-srinivasan-mpls-lans-label-00.txt>                                
  10204.  
  10205.     Multi Protocol Label Switching (MPLS) refers to a forwarding paradigm
  10206.        for routed networks which combines the speed and simplicity of link
  10207.        layer switching with the scalability and control of network layer
  10208.        forwarding.  Routers which support MPLS are referred to as Label
  10209.        Switching Routers (LSRs).  MPLS requires the distribution labels
  10210.        between peer LSRs based on routing and traffic information.  These
  10211.        labels are then carried in packets and are used for making high 
  10212.     speed
  10213.        forwarding decisions at the routers by eliminating the need for
  10214.        conventional network layer header processing.  This note discusses
  10215.        the format and encapsulation of labels when using MPLS on LAN media.
  10216.  
  10217.   "The Use of DES-MAC within ESP and AH", D. Frommer, Sara Bitan, 
  10218.   09/10/1997, <draft-bitan-auth-des-mac-00.txt>                            
  10219.  
  10220.     This draft describes the use of the DES-MAC algorithm [Kaufman95] as
  10221.            an authentication  mechanism within the revised IPSEC 
  10222.     Encapsulating
  10223.     Security  Payload [ESP] and the revised IPSEC Authentication Header 
  10224.     [AH]. DES-MAC[Kaufman95] is based on the DES encryption algorithm 
  10225.     [FIPS-46, FIPS-46-1, FIPS-74, FIPS-81].
  10226.              
  10227.     Further information on the other components necessary for ESP 
  10228.     and AH implementations is provided by [Thayer97a].                     
  10229.  
  10230.   "Salted Challenge Response Authentication Mechanism (SCRAM)", C Newman, 
  10231.   10/06/1997, <draft-newman-auth-scram-01.txt>                             
  10232.  
  10233.          SCRAM is a simple passphrase-based authentication mechanism
  10234.          suitable for a wide variety of usage scenarios.  It combines the
  10235.          best properties of CRAM-MD5 [CRAM-MD5] and OTP [OTP] without a
  10236.          significant increase in complexity.
  10237.     
  10238.          This document defines the SCRAM-MD5 SASL mechanism [SASL] using 
  10239.     the
  10240.          MD5 [MD5] and HMAC-MD5 [HMAC] algorithms.  It is suitable for use
  10241.          directly with protocols such as IMAP [IMAP4] and POP [POP3].      
  10242.  
  10243.   "Confirmation of Mail Message Reception", Alexandre Steinberg, 
  10244.   09/10/1997, <draft-rfced-exp-steinberg-00.txt>                           
  10245.  
  10246.        Currently, Internet SMTP transport does not allow the sender to know
  10247.        if the recipient receive or open a mail message. This limitation
  10248.        frequently causes one question: did my message really arrive? This
  10249.        proposes a simple solution, that could be easy implemented in the
  10250.        mail software.                                                      
  10251.  
  10252.   "The 'news' URL scheme", Alfred Gilman, 09/10/1997, 
  10253.   <draft-gilman-news-url-00.txt>                                           
  10254.  
  10255.     This document defines the format of Uniform Resource Locators
  10256.     (URLs) identifying news messages and groups.  The syntax of
  10257.     'news' URLs from RFC 1738 is extended to allow specification of
  10258.     the site from which the message is to be sought and to
  10259.     incorporate protections via 'snews' URLs.  This combines into the
  10260.     'news' scheme enough capability so that the previously-proposed
  10261.     'nntp' scheme can be retired and URL usage simplified.                 
  10262.  
  10263.   "How to find LDAP servers", R. Moats, 09/26/1997, 
  10264.   <draft-moats-finding-01.txt>                                             
  10265.  
  10266.        This document discusses methods available for LDAP server discovery
  10267.        and advertisement based on previous IETF and ongoing IETF work.     
  10268.  
  10269.   "Pulse-Per-Second API for UNIX", D. Mills, J Mogul, Jan Brittenson, 
  10270.   09/11/1997, <draft-mogul-pps-api-00.txt>                                 
  10271.  
  10272.     RFC1589 describes a UNIX kernel implementation model for
  10273.             high-precision time-keeping.  This is meant for use in
  10274.             conjunction with the Network Time Protocol (NTP, RFC1305),
  10275.             or similar time synchronization protocols.  One aspect of
  10276.             this model is an accurate interface to the high-accuracy,
  10277.             one pulse-per-second (PPS) output typically available from
  10278.             precise time sources (such as a GPS or GOES receiver).
  10279.             RFC1589 did not define an API for managing the PPS
  10280.             facility.  This document specifies such an API.                
  10281.  
  10282.   "Avoiding the TCP TIME_WAIT state at Busy Servers", J. Touch, Ted Faber, 
  10283.   Wei Yue, 09/11/1997, <draft-faber-time-wait-avoidance-00.txt>            
  10284.  
  10285.           This document describes the problems associated with the 
  10286.     accumulation
  10287.        of TCP TIME_WAIT states at a network server, such as a web server,
  10288.        and details two methods for avoiding that accumulation.  Servers 
  10289.     that
  10290.        have many TCP connections in TIME_WAIT state experience performance
  10291.        degradation, and can collapse.  One solution is a TCP modification
  10292.        that causes clients to enter TIME_WAIT state rather than servers.
  10293.        The other is an HTTP modification that allows the client to close 
  10294.     the
  10295.        transport connection, maintaining the TIME_WAIT state at the client.
  10296.        The goal of both approaches is ensure that TIME_WAIT states accumu-
  10297.        late at the less loaded endpoint.
  10298.     
  10299.        The document also presents initial performance data from reference
  10300.        implementations of these solutions, which suggest that the modifica-
  10301.        tions improve HTTP connection rates at the server by as much as 50%,
  10302.        and allow servers to operate at small transaction throughputs that
  10303.        they cannot sustain their default configuration.                    
  10304.  
  10305.   "Extending POP Version 3 To Do Mailbox Compression", Harish Pillay, 
  10306.   Marvin Tay, 09/11/1997, <draft-pillay-pop3-ext-00.txt>                   
  10307.  
  10308.             This document suggests an extension to the Post Office Protocol
  10309.             version 3 (RFC 1725) that adds an extra command to selective
  10310.             compress the maildrop before transferring the mail to the
  10311.             recipient.
  10312.      
  10313.             Given the extensive and explosive growth of mobile uses of the
  10314.             Internet especially the numbers of people who access their 
  10315.     e-mail
  10316.             via dialup modems, it does not make sense to have to transfer
  10317.             e-mail to the client in uncompressed form.
  10318.      
  10319.             This draft discusses a new command that will make the pop3 
  10320.     server
  10321.             to intelligently compress the maildrop into a single file and
  10322.             then for it to be sent to the client.  The client will then
  10323.             process the compressed mail accordingly.                       
  10324.  
  10325.   "The SRP Authentication and Key Exchange System", Tom Wu, 09/11/1997, 
  10326.   <draft-wu-srp-auth-00.txt>                                               
  10327.  
  10328.     This document describes a cryptographically strong network
  10329.        authentication mechanism known as the Secure Remote Password (SRP)
  10330.        protocol.  This mechanism is suitable for negotiating secure
  10331.        connections using a user-supplied password, while eliminating the
  10332.        security problems traditionally associated with reusable passwords.
  10333.        This system also performs a secure key exchange in the process of
  10334.        authentication, allowing security layers (privacy and/or integrity
  10335.        protection) to be enabled during the session.  Trusted key servers
  10336.        and certificate infrastructures are not required, and clients are
  10337.        not required to store or manage any long-term keys.  SRP offers
  10338.        both security and deployment advantages over existing challenge-
  10339.        response techniques, making it an ideal drop-in replacement where
  10340.        secure password authentication is needed.                           
  10341.  
  10342.   "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", M. Crispin, 
  10343.   10/10/1997, <draft-crispin-imapv-02.txt>                                 
  10344.  
  10345.         The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1)
  10346.        allows a client to access and manipulate electronic mail messages on
  10347.        a server.  IMAP4rev1 permits manipulation of mailboxes (remote
  10348.        message folders) in a way that is functionally equivalent to local
  10349.        folders.  IMAP4rev1 also provides the capability for an offline
  10350.        client to resynchronize with the server (see also [IMAP-DISC]).
  10351.     
  10352.        IMAP4rev1 includes operations for creating, deleting, and renaming
  10353.        mailboxes; checking for new messages; permanently removing messages;
  10354.        setting and clearing flags; [RFC-822] and [MIME-IMB] parsing;
  10355.        searching; and selective fetching of message attributes, texts, and
  10356.        portions thereof.  Messages in IMAP4rev1 are accessed by the use of
  10357.        numbers.  These numbers are either message sequence numbers or 
  10358.     unique
  10359.        identifiers.
  10360.      
  10361.        IMAP4rev1 supports a single server.  A mechanism for accessing
  10362.        configuration information to support multiple IMAP4rev1 servers is
  10363.        discussed in [ACAP].
  10364.      
  10365.        IMAP4rev1 does not specify a means of posting mail; this function is
  10366.        handled by a mail transfer protocol such as [SMTP].
  10367.      
  10368.        IMAP4rev1 is designed to be upwards compatible from the [IMAP2] and
  10369.        unpublished IMAP2bis protocols.  In the course of the evolution of
  10370.        IMAP4rev1, some aspects in the earlier protocol have become 
  10371.     obsolete.
  10372.        Obsolete commands, responses, and data formats which an IMAP4rev1
  10373.        implementation can encounter when used with an earlier 
  10374.     implementation
  10375.        are described in [IMAP-OBSOLETE].
  10376.     
  10377.        Other compatibility issues with IMAP2bis, the most common variant of
  10378.        the earlier protocol, are discussed in [IMAP-COMPAT].  A full
  10379.        discussion of compatibility issues with rare (and presumed extinct)
  10380.        variants of [IMAP2] is in [IMAP-HISTORICAL]; this document is
  10381.        primarily of historical interest.                                   
  10382.  
  10383.   "Generation of the Age header field in HTTP/1.1", J Mogul, 09/15/1997, 
  10384.   <draft-mogul-http-age-00.txt>                                            
  10385.  
  10386.     The 'Age' response-header field in HTTP/1.1 [RFC 2068] is
  10387.             intended to provide a lower bound of an estimate of a
  10388.             response message's age (time since generation), by
  10389.             explicitly indicating the amount of time that is known to
  10390.             have passed since the response message was retrieved or
  10391.             revalidated.  There has been considerable controversy over
  10392.             when the Age header field should be added to a response.
  10393.             This document explains the issues, rebuts a previous
  10394.             proposal, and provides a set of proposed changes for the
  10395.             revision of RFC 2068.                                          
  10396.  
  10397.   "Use of Label Switching With Frame Relay Specification", A. Conta, P. 
  10398.   Doolan, 09/15/1997, <draft-conta-mpls-fr-00.txt>                         
  10399.  
  10400.     This  document  defines  the  model  and   generic   mechanisms   for
  10401.     Multiprotocol   Label   Switching   on   Frame   Relay   networks.  A
  10402.     Multiprotocol Label Switching Architecture is  described  in  [ARCH].
  10403.     MPLS  enables  the  use  of  Frame  Relay Switches as Label Switching
  10404.     Routers (LSRs). The Frame Relay Switches run  network  layer  routing
  10405.     algorithms  (such as OSPF, IS-IS, etc.), and their data forwarding is
  10406.     based on the results of these routing  algorithms.  No  Frame  Relay-
  10407.     specific routing is needed.                                            
  10408.  
  10409.   "Internet Protocol Multicast Problem Statement", Scott Bradner, 
  10410.   09/15/1997, <draft-bradner-multicast-problem-00.txt>                     
  10411.  
  10412.     This document outlines the evolving requirements for Multicast
  10413.        functionality within next generation Internet Protocol networks, and
  10414.        is the product of an ad hoc Internet2 working group meeting held
  10415.        August 25-27, 1997 hosted by Cisco Systems, Inc. This document is
  10416.        offered to the IP community for its consideration and comments.     
  10417.  
  10418.   "Internet Protocol Quality of Service Problem Statement", Scott Bradner, 
  10419.   09/15/1997, <draft-bradner-qos-problem-00.txt>                           
  10420.  
  10421.        This document outlines the requirements for a Quality of Service
  10422.        (QoS) function for the Internet Protocol, and is the product of an 
  10423.     ad
  10424.        hoc Internet 2 working group meeting held August 25-27, 1997 hosted
  10425.        by Cisco Systems, Inc. This document is offered to the IP community
  10426.        for its consideration and comments.
  10427.      
  10428.        This document is organized as follows: Section 1 proposes a simple
  10429.        classification scheme to describe QoS models. Subsequent sections
  10430.        discuss requirements for Measurement, Administrative Policy,
  10431.        Provisioning Issues, Network Environment and Implementation Issues. 
  10432.  
  10433.   "Telnet Authentication: SRP", Tom Wu, 09/18/1997, 
  10434.   <draft-wu-telnet-auth-srp-00.txt>                                        
  10435.  
  10436.     This document specifies an authentication scheme for the Telnet
  10437.        protocol under the framework described in RFC 1416, using the
  10438.        recently proposed SRP authentication mechanism.                     
  10439.  
  10440.   "RIDE referencing", David R. Conrad, Wilfried Woeber, David Kessens, 
  10441.   09/19/1997, <draft-kessens-ride-referencing-00.txt>                      
  10442.  
  10443.        This document describes two variants of a proposal on how to find
  10444.        information regarding some critical resources (domain names, IP
  10445.        addresses and routing registry information) on the Internet. The
  10446.        proposed solution uses globally unique registry identifiers that are
  10447.        derived from a domain name in use by a registry.                    
  10448.  
  10449.   "RIDE functional requirements", David Kessens, 09/19/1997, 
  10450.   <draft-kessens-ride-requirements-00.txt>                                 
  10451.  
  10452.        This document describes the (functional) requirements for the RIDE
  10453.        format and protocols.                                               
  10454.  
  10455.   "IPv6 over Point-to-Point ATM Link", K. Yamamoto, Yoshinobu Inoue, 
  10456.   Hiroshi Esaki, Yoshifumi Atarashi, Kenjiro Cho, 09/22/1997, 
  10457.   <draft-yamamoto-ipv6-over-p2p-atm-00.txt>                                
  10458.  
  10459.         This memo defines a communication mechanism to exchange both IPv6
  10460.         unicast and multicast packets over an ATM network used as a
  10461.         point-to-point link.                                               
  10462.  
  10463.   "Communicating Information for External Program Use in Internet Messages:
  10464.   The Process Content-Disposition Type", Curtis Whalen, 09/22/1997, 
  10465.   <draft-rfced-exp-whalen-00.txt>                                          
  10466.  
  10467.        This memo provides a mechanism whereby messages conforming to the
  10468.        MIME specifications [RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC
  10469.        2049] can convey information not intended for display by the Mail
  10470.        User Agent (UA), but for processing (as opposed to display) by an
  10471.        external program.  It specifies a new type of 'Content-Disposition'
  10472.        (defined by [RFC 2183]), which is valid for any MIME entity
  10473.        ('message' or 'body part).  When 'body part' is referred to in this
  10474.        memo, it is referring to any MIME entity, except in section 2.4. 
  10475.     This
  10476.        memo is the definition of this type, as specified by Section 9 of
  10477.        [RFC 2183].
  10478.     
  10479.        This document is intended as an extension to MIME.  As such, the
  10480.        reader is assumed to be familiar with the MIME specifications,
  10481.        [RFC 822], and [RFC 2183].  The information presented herein
  10482.        supplements but does not replace that found in those documents.     
  10483.  
  10484.   "VCID: Virtual Connection Identifier", Noritoshi Demizu, Hiroshi Esaki, 
  10485.   K. Nagami, P. Doolan, 10/07/1997, <draft-demizu-mpls-vcid-01.txt>        
  10486.  
  10487.        Several label switching schemes have been proposed to fuse and
  10488.        integrate the cost-performance and QoS assurance of Layer 2 devices
  10489.        and the flexibility and functionality of Layer 3 protocols.
  10490.      
  10491.        Some of these proposals assume that Label Switching Routers (LSRs)
  10492.        are placed in a homogeneous LSR cloud in a campus area network or a
  10493.        backbone network, and they are connected directly to each other.
  10494.        However, this assumption sometimes does not hold true in the real
  10495.        situation.  For example, some campuses will be connected via ATM SVC
  10496.        service, and LSR networks will be constructed hierarchically.
  10497.      
  10498.        To deal with Virtual Connections (VCs) in these environments, this
  10499.        document proposes to identify a VC with a VCID instead of a label.  
  10500.  
  10501.   "Automated Digital Network System Description", Rex Buddenberg, 
  10502.   09/23/1997, <draft-rfced-info-buddenberg-00.txt>                         
  10503.  
  10504.     The Navy's Automated Digital Network System (ADNS) provides a means
  10505.     for ship's to centralize and automate the operation of multiple
  10506.     independent radio communications systems into an efficient
  10507.     communications network.                                                
  10508.  
  10509.   "Using LDAP for SMTP Mailing Lists & Aliases", Bruce Steinback, 
  10510.   09/24/1997, <draft-steinback-ldap-mailgroups-00.txt>                     
  10511.  
  10512.        Directory services based on the Lightweight Directory Access 
  10513.     Protocol
  10514.        (LDAP) [1] and X.500 [2] provide a general-purpose means to store
  10515.        information about users and other network entities.  One such use is
  10516.        to store information on groups.  There are LDAP standards 
  10517.     established
  10518.        for this purpose, e.g. the groupOfUniqueNames [3].  However,
  10519.        currently there are no standards for a very important use of Groups,
  10520.        as SMTP Mailing Lists or Aliases.
  10521.     
  10522.        This document discusses how we at Netscape have made this extension,
  10523.        with the intent of providing useful information towards perhaps
  10524.        creating standards for this important use of LDAP.                  
  10525.  
  10526.   "SDP syntax for H.263 options", Petri Koskelainen, 09/26/1997, 
  10527.   <draft-koskelainen-sdp263-00.txt>                                        
  10528.  
  10529.     This document defines the SDP syntax for H.263 codec options and
  10530.     parameters for IETF multimedia conferencing architecture. It is often
  10531.     useful to know beforehand (in call setup phase) what features of H.263
  10532.     the other end supports. This document specifies the format spefic
  10533.     parameters for H.263, which exists in a=fmtp:<format> <format specific
  10534.     parameters> as defined in the SDP document.
  10535.     Chapters 4 and 5 specify their usage with two popular IETF protocols,
  10536.     SIP and SAP.                                                           
  10537.  
  10538.   "Mapping Financial Transaction Card Numbers into the Domain Name System",
  10539.   Don Eastlake, 09/29/1997, <draft-eastlake-card-map-00.txt>               
  10540.  
  10541.        The SET protocol being developed by the VISA and MasterCard
  10542.        associations and others assumes that a financial transaction
  10543.        cardholder can locate the appropriate certification authority to
  10544.        obtain a cardholder certificate.  This document proposes a method
  10545.        using the DNS and, in some cases the referral features of the SET
  10546.        protocol, to locate such certification authorities and other
  10547.        financial transaction card related facilities on the Internet by
  10548.        mapping ISO 7812 derived card numbers into domain names within in 
  10549.     the
  10550.        card.int domain.                                                    
  10551.  
  10552.   "Use of the IPv4 TOS Octet to Support Differential Services", Juha 
  10553.   Heinanen, 10/02/1997, <draft-heinanen-diff-tos-octet-00.txt>             
  10554.  
  10555.     This document describes how the TOS octet in the IPv4 header can be
  10556.        used to support differential Internet services.  The proposal is
  10557.        based on the existing format of the TOS octet as defined in [RFC791]
  10558.        and [RFC1349].                                                      
  10559.  
  10560.   "Two Modes of MPLS Explicit Label Distribution Protocol", Y. Katsube, K. 
  10561.   Nagami, Y. Ohba, 10/06/1997, <draft-katsube-mpls-two-ldp-00.txt>         
  10562.  
  10563.        This memo discusses characteristics of two types of MPLS protocol
  10564.        operations, which we call 'Edge Control' operation and
  10565.        'Distributed' operation individually, and proposes that these two
  10566.        mode of protocol operations should be specified as the explicit
  10567.        Label Distribution Protocol for the MPLS.                           
  10568.  
  10569.   "VC Pool", Noritoshi Demizu, Hiroshi Esaki, K. Nagami, P. Doolan, 
  10570.   10/07/1997, <draft-demizu-mpls-vcpool-00.txt>                            
  10571.  
  10572.        Several label switching schemes have been proposed to fuse and
  10573.        integrate Layer 2 and Layer 3.  They can be applied to various
  10574.        datalinks including intermittent links such as ATM SVC.
  10575.      
  10576.        Intermittent links require signaling to establish VCs before
  10577.        employing them and to release VCs after utilizing them.  Because
  10578.        signaling often introduces delays and costs, some kind of
  10579.        optimization is necessary.
  10580.      
  10581.        This document proposes to introduce a VC pool to reduce the delays
  10582.        and the costs of signaling.                                         
  10583.  
  10584.   "ATM SVC Support for ATM-LSRs", Noritoshi Demizu, Hiroshi Esaki, K. 
  10585.   Nagami, P. Doolan, 10/07/1997, <draft-demizu-mpls-atm-svc-00.txt>        
  10586.  
  10587.     Several label switching schemes have been proposed to fuse and
  10588.        integrate Layer 2 and Layer 3.  ATM Label Switching Router (ATM-LSR)
  10589.        is one of the major applications of label switching.  Some ATM-LSRs
  10590.        will need to support ATM SVC services, which requires signaling to
  10591.        establish VCs before employing them and to release VCs after
  10592.        utilizing them.  This document proposes procedures to deal with ATM
  10593.        SVCs between ATM-LSRs.                                              
  10594.  
  10595.   "Registration of a Ukrainian Cyrillic Character Set KOI8-RU (as extention
  10596.   to Russian KOI8-R and ISO-IR-111)", Yuri Demchenko, 10/07/1997, 
  10597.   <draft-rfced-info-demchenko-00.txt>                                      
  10598.  
  10599.        This document provides information about widely
  10600.        used in Ukrainian Internet community character set for mail and news
  10601.        exchange as well as for presentation WWW information resources in
  10602.        Ukrainian language.                                                 
  10603.  
  10604.   "The Boot Selection Menu Option for BOOTP/DHCP", Bharat Madan, 
  10605.   10/10/1997, <draft-rfced-info-madan-00.txt>                              
  10606.  
  10607.        The BOOTP [1] or the Dynamic Host Configuration Protocol (DHCP) [2]
  10608.        provide a framework for booting a host over a network from a remote
  10609.        server. This document defines a new option which a BOOTP/DHCP client
  10610.        may include in its BOOTP request or DHCPDISCOVER message. In their
  10611.        replies, the  recipient servers may include this option  along with
  10612.        the location/path information to a file ('boot.info') in the option
  10613.        field. The client may use the contents of this file to select the
  10614.        desired  OS  with which to boot along with the location/path of the
  10615.        appropriate boot image file.                                        
  10616.  
  10617.   "A MIME Directory Profile for LDAP Schema", M. Wahl, 10/13/1997, 
  10618.   <draft-wahl-mime-schema-00.txt>                                          
  10619.  
  10620.     This document defines a MIME directory profile [1] for holding an
  10621.        LDAP [2] schema.  It is intended for communication with the Internet
  10622.        schema listing service [3].                                         
  10623.  
  10624.   "Security issues for the ATMARP protocol", G. Armitage, 10/13/1997, 
  10625.   <draft-armitage-ion-sec-arp-00.txt>                                      
  10626.  
  10627.     This document discusses some security issues associated with IP over
  10628.        ATM operation. RFC1577 defines the Classic IP model for sending IP
  10629.        traffic over ATM. However, security issues were not addressed in the
  10630.        standard. Since internet is an open architecture, security measures
  10631.        to protect network integrity are essential for normal operation. The
  10632.        security loopholes in the current RFC 1577 model are analyzed and
  10633.        discussed. Possible solutions are proposed.                         
  10634.  
  10635.   "HTTP Traffic over Satellite", Robert Pohlmann, 10/14/1997, 
  10636.   <draft-pohlmann-http-traffic-satellite-00.txt>                           
  10637.  
  10638.     Internet use over satellites (LEO, MEO and GEO) has not
  10639.     received enough attention.  Satellites have an inherent
  10640.     broadcasting ability useful for transmitting Internet
  10641.     traffic.  They can send information to many locations
  10642.     simultaneously depending on the coverage beam of the
  10643.     satellite.  The issue of Internet use over satellites needs
  10644.     to be addressed so that future implementations of networking
  10645.     protocols can be used with this medium.  The vast majority
  10646.     of Internet traffic is TCP traffic resulting from the HTTP
  10647.     protocol so this issue will be addressed here.  It is hoped
  10648.     that this facilitates the transition from the use of
  10649.     terrestial networks, to networks incorporating satellite
  10650.     links.                                                                 
  10651.  
  10652.   "Identification of messages delivered via both mail and news", J. 
  10653.   Zawinski, 10/14/1997, <draft-zawinski-posted-to-00.txt>                  
  10654.  
  10655.     This draft defines a format to be used when delivering a single message
  10656.     to multiple destinations, where some destinations are newsgroups and
  10657.     some destinations are email mailboxes.                                 
  10658.  
  10659.   "Ukrainian Code Page KOI8-U", Roman Tkachuk, 10/14/1997, 
  10660.   <draft-rfced-info-tkachuk-00.txt>                                        
  10661.  
  10662.        This memo is the specification of the code page, which was 
  10663.     originally
  10664.        developed for the transmission of texts in the Ukrainian language
  10665.        through networks, and in particular the networks, employing Unix
  10666.        operating systems. It is, however, operating-system-neutral, and is
  10667.        used in various situations, just as its Russian language counterpart
  10668.        KOI-8R.
  10669.          
  10670.        With some minor exceptions, this specification can be considered
  10671.        to be an extension of KOI8-R (RFC-1489). The present edition of the
  10672.        specification is the result of the wide concensus reached after many
  10673.        prolonged exchanges and discussions, which took place in Ukraine and
  10674.        on some Usenet conferences covering Ukraine and read by the public
  10675.        who employs the Ukrainian language.                                 
  10676.  
  10677.   "LDAP Schema for Role Based Access Control", Larry Bartz, 10/14/1997, 
  10678.   <draft-bartz-hyperdrive-ldap-rbac-schema-00.txt>                         
  10679.  
  10680.         Role Based Access Control (RBAC) is an authorization strategy in
  10681.        which an entity's permission to access and manipulate targeted
  10682.        resources is determined by the entity's role or function within a
  10683.        certain organizational context. RBAC's principal motivation is to
  10684.        streamline security policy administration. Many discrete authoriza-
  10685.        tions can be aggregated within a defined role. One or many roles may
  10686.        be assigned or attributed to individuals. This draft describes LDAP
  10687.        object classes and attributes which support RBAC. Adoption of this
  10688.        schema across multiple LDAP implementations will enable RBAC intero-
  10689.        perability among heterogeneous underlying directory services.       
  10690.  
  10691.   "Directory Schema Listing File Name Syntax", Chris Apple, 10/16/1997, 
  10692.   <draft-apple-schema-file-list-00.txt>                                    
  10693.  
  10694.     This memo specifies a file name syntax for use by the primary listing
  10695.        repository operator of the directory schema listing service.        
  10696.  
  10697.   "Access Control Requirements for LDAP", B. Blakley, E. Stokes, Debbie 
  10698.   Byrne, Prasanta Behera, 10/17/1997, 
  10699.   <draft-stokes-ldapext-acl-reqts-00.txt>                                  
  10700.  
  10701.     This document describes the fundamental requirements of
  10702.                  an access control list (ACL) model for the Lightweight
  10703.                  Directory Application Protocol (LDAP) directory service.
  10704.                  It is intended to be a gathering place for access control
  10705.                  requirements needed to provide authorized access to and
  10706.                  interoperability between directories. The RFC 2119 
  10707.     terminology is used in this document.                                  
  10708.  
  10709.   "Requirements for Distinguished Names in Autonomous to Loosely-coupled 
  10710.   LDAP-based Directory Services", J. Hodges, 10/21/1997, 
  10711.   <draft-hodges-ldap-dir-dn-reqs-00.txt>                                   
  10712.  
  10713.     This document analyzes the issues involved in the Distinguished Name-
  10714.     spaces of autonomous to loosely-coupled, LDAP-based directory services
  10715.     (LLDSs). It folds in experience learned from the global X.500-based 
  10716.     Dis-
  10717.     tinguished Name-space, and proposes requirements for the construction 
  10718.     of
  10719.     Distinguished Names for LLDSs of varying scopes.                       
  10720.  
  10721.   "URLs for GSM Short Message Service", Antti Vaha-Sipila, 10/21/1997, 
  10722.   <draft-antti-gsm-sms-url-00.txt>                                         
  10723.  
  10724.         This document specifies a URL (Uniform Resource Locator) scheme
  10725.         'gsms' for specifying a recipient for an alphanumeric message
  10726.         (Short Message) in a GSM-based mobile phone system. Short Messages
  10727.         are two-way paging messages that can be sent from a suitable
  10728.         equipped computer or a phone.                                      
  10729.  
  10730.   "PPP Over SONET Mapping", Jon Anderson, Al White, Demos Kostas, Brent 
  10731.   Allen, 10/23/1997, <draft-allen-pppsonet-mapping-00.txt>                 
  10732.  
  10733.     This Internet Draft addresses the PPP/SONET interface defined
  10734.     in the IETF RFC 1619 and the standards work underway in T1X1 on
  10735.     SONET.                                                                 
  10736.  
  10737.   "One Planet, One Net:  Principles for the Internet Era", Nathaniel 
  10738.   Borenstein, Harry Hochheiser, 10/23/1997, <draft-cpsr-one-net-00.txt>    
  10739.  
  10740.     This document presents a suggested set of basic principles
  10741.                 that the authors believe should underlie all future work in
  10742.                 the area of Internet governance.  The purpose of this
  10743.                 document is to work towards as broad a consensus as
  10744.                 possible, in the diverse Internet community, about
  10745.                 principles that should inform the way the Internet is
  10746.                 administered for the benefit of all humanity.
  10747.     
  10748.                 The principles have been drafted under the auspices of
  10749.                 Computer Professionals for Social Responsibility, with
  10750.                 several iterations internal to that organization.  However,
  10751.                 they are still very much seen as a work in progress.
  10752.                 Comments are solicited from all interested parties.  Future
  10753.                 versions will be refined based on these comments and
  10754.                 published as future Internet-Drafts, with a goal of
  10755.                 publication of a finalized version of the declaration as an
  10756.                 Internet RFC in summer, 1998.
  10757.     
  10758.                 All comments on this document are welcome; please send them
  10759.                 to onenet-comments@cpsr.org.  Open discussion of this
  10760.                 document is encouraged on the onenet-discuss list, which is
  10761.                 archived at http://www.findmail.com/listsaver/onenet-
  10762.                 discuss.                                                   
  10763.  
  10764.   "Self-Describing Data Representation (SDR)", Colin Low, Jim Randell, Mike
  10765.   Wray, 10/23/1997, <draft-low-sdr-00.txt>                                 
  10766.  
  10767.        This document describes a human-readable, textual syntax for
  10768.        representing self-describing structured data. This representation 
  10769.     was
  10770.        designed as a transfer syntax for loosely-coupled distributed
  10771.        applications where one cannot depend on sender(s) and receiver(s)
  10772.        sharing a schema for exchanged data. The syntax is compact,
  10773.        expressive, intuitive, and simple to implement.                     
  10774.  
  10775.   "''shared-mtrace'': A Multicast 'traceroute' facility for Shared Trees", 
  10776.   Tony Ballardie, 10/27/1997, <draft-ballardie-shared-mtrace-00.txt>       
  10777.  
  10778.        ''mtrace'' [1] is a very useful tool for diagnosing IP multicast 
  10779.     rout-
  10780.        ing problems, such as multicast routing loops and misconfigured mul-
  10781.        ticast routers, associated with source-rooted RPF-based distribution
  10782.        trees.
  10783.      
  10784.        For ''mtrace'' to be useful in a shared tree environment (e.g. PIM 
  10785.     [2],
  10786.        CBT [3], GUM [4]) its behaviour must be modified. This draft speci-
  10787.        fies that behaviour, which is sufficiently general to be applicable
  10788.        to all shared tree types and operating modes.  A new ''wildcard'' 
  10789.     mode
  10790.        of behaviour is also described, which allows a trace of a complete
  10791.        shared tree.  Authentication is recommended in this mode because of
  10792.        its potential as a vehicle for denial of service attacks.
  10793.      
  10794.        It is intended that this draft become a document of the Mbone 
  10795.     Deploy-
  10796.        ment (mboned) working group of the IETF. Therefore, comments are 
  10797.     solicited and should be sent to mboned's mailing list <mboned@network-
  10798.        services.uoregon.edu> and/or the author.                            
  10799.  
  10800.   "HARP - ''Home Agent Redundancy Protocol''", Jim Binkley, Bjorn 
  10801.   Chambless, 10/30/1997, <draft-chambless-mobileip-harp-00.txt>            
  10802.  
  10803.     This document presents a protocol called the Home Agent Redundancy
  10804.        Protocol or HARP.  HARP is an optional extension to Mobile-IP [RFC-
  10805.        2002].  Mobile-IP includes the notion of a Home Agent which is
  10806.        a host located on the home IP subnet for Mobile Nodes.  Home Agents
  10807.        forward packets to Mobile Nodes that are away from home.  Since 
  10808.     Mobile
  10809.        Nodes are dependent on the Home Agent for connectivity when away 
  10810.     from
  10811.        home, the Home Agent represents a possible single source of failure 
  10812.     for
  10813.        the Mobile IP system.
  10814.      
  10815.        HARP is a protocol which allows a pair (or set) of Home Agents
  10816.        to cooperate and share Mobile-IP Mobile Node registration
  10817.        information.  If one of the HARP peers should fail, the Mobile-IP
  10818.        system will not necessarily fail, hence HARP introduces Home
  10819.        Agent redundancy into the Mobile-IP system.  Mobile Nodes are
  10820.        not aware that HARP exists, so HARP requires no changes to
  10821.        Mobile-IP as a protocol.  In this document, we present the HARP
  10822.        architecture and protocol.                                          
  10823.  
  10824.   "Cryptographic Message Syntax", Russ Housley, 10/31/1997, 
  10825.   <draft-housley-smime-cms-00.txt>                                         
  10826.  
  10827.        This document describes the Cryptographic Message Syntax.  This
  10828.        syntax is used to digitally sign or encrypt arbitrary messages.
  10829.      
  10830.        The Cryptographic Message Syntax is deriveded from PKCS #7 version
  10831.        1.5.  Wherever possible, backward compatibility is preserved;
  10832.        however, changes were necessary to accomodate attribute certificate
  10833.        transfer and key agreement techniques for key management.
  10834.      
  10835.        Please send comments on this document to the ietf-smime@imc.com mail
  10836.        list.                                                               
  10837.  
  10838.   "MIME Parameter Value and Encoded Word Extensions: Character Sets, 
  10839.   Languages, and Continuations", Ned Freed, Keith Moore, 10/31/1997, 
  10840.   <draft-freed-pvcsc-new-00.txt>                                           
  10841.  
  10842.     This memo defines extensions to the RFC 2045 media type and
  10843.     RFC 2183 disposition parameter value mechanisms to provide
  10844.      
  10845.      (1)   a means to specify parameter values in character sets
  10846.            other than US-ASCII,
  10847.     
  10848.      (2)   to specify the language to be used should the value be
  10849.            displayed, and
  10850.      
  10851.      (3)   a continuation mechanism for long parameter values to
  10852.            avoid problems with header line wrapping.
  10853.      
  10854.     This memo also defines an extension to the encoded words
  10855.     defined in RFC 2047 to allow the specification of the language
  10856.     to be used for display as well as the character set.                   
  10857.  
  10858.   "DNS and URL Level Addressing for Public Circuit-Switching Network 
  10859.   Devices", H. Zhu, 10/31/1997, <draft-zhu-dns-url-level-addr-00.txt>      
  10860.  
  10861.     Recently there are a number of efforts [sw1, sw2, in,tpc, etc.] of 
  10862.     trying to
  10863.     connect the packet-switching network with circuit-switching network, 
  10864.     especially
  10865.     connecting the Internet with public telephone networks.  The first 
  10866.     problem
  10867.     of such interconnection is naming and addressing, later will come with
  10868.     directory services and routing problems.  This draft concentrates on
  10869.     naming for DNS and URL.  Other problems are discussed in other 
  10870.     documents
  10871.     [utrpt, framework].                                                    
  10872.  
  10873. ONC Remote Procedure Call (oncrpc)
  10874. ----------------------------------
  10875.  
  10876.   "Authentication Mechanisms for ONC RPC", Steve Nahm, 10/22/1997, 
  10877.   <draft-ietf-oncrpc-auth-04.txt>                                          
  10878.  
  10879.     This document describes two authentication mechanisms created by Sun
  10880.     Microsystems that are commonly used in conjunction with the ONC Remote
  10881.     Procedure Call (ONC RPC Version 2) protocol.                           
  10882.  
  10883.   "RPC: Remote Procedure Call Protocol Specification Version 2", R. 
  10884.   Srinivasan, Steve Nahm, 04/22/1997, <draft-ietf-oncrpc-remote-03.txt>    
  10885.  
  10886.     This document describes the ONC Remote Procedure Call (ONC RPC Version 
  10887.     2) protocol as it is currently deployed and accepted.  'ONC' stands for
  10888.     'Open Network Computing'.                                              
  10889.  
  10890. Open Shortest Path First IGP (ospf)
  10891. -----------------------------------
  10892.  
  10893.   "OSPF for IPv6", Rob Coltun, John Moy, D. Ferguson, 03/26/1997, 
  10894.   <draft-ietf-ospf-ospfv6-04.txt>                                          
  10895.  
  10896.     This document describes the modifications to OSPF to support version 6 
  10897.     of the Internet Protocol (IPv6).  The fundamental mechanisms of OSPF 
  10898.     (flooding, DR election, area support, SPF calculations, etc.) remain 
  10899.     unchanged. However, some changes have been necessary, either due to 
  10900.     changes in protocol semantics between IPv4 and IPv6, or simply to 
  10901.     handle the increased address size of IPv6.  Changes between OSPF for 
  10902.     IPv4 and this document include the following. Addressing semantics have
  10903.     been removed from OSPF packets and the basic LSAs. New LSAs have been 
  10904.     created to carry IPv6 addresses and prefixes. OSPF now runs on a 
  10905.     per-link basis, instead of on a per-IP-subnet basis. Flooding scope for
  10906.     LSAs has been generalized. Authentication has been removed from the 
  10907.     OSPF protocol itself, instead relying on IPv6's Authentication Header 
  10908.     and Encapsulating Security Payload.   Most packets in OSPF for IPv6 are
  10909.     almost as compact as those in OSPF for IPv4, even with the larger IPv6 
  10910.     addresses. Most field- and packet-size limitations present in OSPF for 
  10911.     IPv4 have been relaxed.  In addition, option handling has been made 
  10912.     more flexible.                                                         
  10913.  
  10914.   "The OSPF Opaque LSA Option", Rob Coltun, 05/01/1997, 
  10915.   <draft-ietf-ospf-opaque-01.txt>                                          
  10916.  
  10917.     This memo documents enhancements to the OSPF protocol to support a new 
  10918.     class of link-state advertisements (LSA) called Opaque LSAs.  The 
  10919.     Opaque LSA option defines a general mechanism to allow for future 
  10920.     extensibility of OSPF. The information contained in Opaque LSAs may be 
  10921.     used directly by OSPF or by other protocols.  Opaque LSAs contain some 
  10922.     number of octets padded to 32-bit alignment.  The standard OSPF 
  10923.     link-state database flooding mechanisms are use for distribution of 
  10924.     Opaque LSAs.  Opaque LSAs are flooded throughout all or some limited 
  10925.     portion of the OSPF topology.                                          
  10926.  
  10927.   "OSPF Standardization Report", John Moy, 05/02/1997, 
  10928.   <draft-ietf-ospf-stdreport-02.txt>                                       
  10929.  
  10930.     This memo documents how the requirements for advancing a routing 
  10931.     protocol to Full Standard, set out in [Ref2], have been met for OSPFv2.
  10932.     Please send comments to ospf@gated.cornell.edu.                        
  10933.  
  10934.   "The OSPF NSSA Option", Rob Coltun, Vince Fuller, P. Murphy, 06/03/1997, 
  10935.   <draft-ietf-ospf-nssa-update-02.txt>                                     
  10936.  
  10937.     This memo documents of an optional type of OSPF area which is somewhat 
  10938.     humorously referred to as a 'not-so-stubby' area (or NSSA). NSSAs are 
  10939.     similar to the existing OSPF stub area configuration option but have 
  10940.     the additional capability of importing AS external routes in a limited 
  10941.     fashion.                                                               
  10942.     The OSPF NSSA Option was originally defined in RFC 1587.  The 
  10943.     functional differences between this memo and RFC 1587 are explained in 
  10944.     Appendix D.  All differences, while expanding capability, are 
  10945.     backward-compatible in nature.  Implementations of this memo and of RFC
  10946.     1587 will interoperate.   Please send comments to 
  10947.     ospf@gated.cornell.edu.                                                
  10948.  
  10949.   "The OSPF Address Resolution Advertisement Option", Rob Coltun, Juha 
  10950.   Heinanen, 08/04/1997, <draft-ietf-ospf-ara-00.txt>                       
  10951.  
  10952.     This document defines an OSPF option which enables routers to distri-
  10953.     bute IP to link-layer address resolution information.  An OSPF Address
  10954.     Resolution Advertisement (ARA) may include link-layer specific func-
  10955.     tionality such as a multipoint-to-point connection identifier along
  10956.     with the address resolution information.  The ARA option can be used
  10957.     to support router-to-router inter-subnet shortcut architectures such
  10958.     as those described in [HEIN]                                           
  10959.  
  10960.   "OSPFv2 Domain Of Interpretation (DOI) for ISAKMP", Ran Atkinson, 
  10961.   10/16/1997, <draft-ietf-ospf-doi-00.txt>                                 
  10962.  
  10963.           The Internet Security  Association  and  Key  Management  
  10964.     Protocol
  10965.        (ISAKMP)  defines a framework for security association management 
  10966.     and
  10967.        cryptographic key establishment for  the  Internet.   This  
  10968.     framework
  10969.        consists  of  defined  exchanges and processing guidelines that 
  10970.     occur
  10971.        within a given Domain of Interpretation (DOI).  This document 
  10972.     details the  OSPFv2  DOI,  which  is  defined  to  cover the use of 
  10973.     ISAKMP to
  10974.        negotiate Security Associations for the OSPFv2 routing protocol.    
  10975.  
  10976.   "SPF over ATM and Proxy PAR", T. Przygienda, Patrick Droz, 10/31/1997, 
  10977.   <draft-ietf-ospf-atm-00.txt>                                             
  10978.  
  10979.     This draft specifes for OSPF implementors and users mechanisms
  10980.        describing how the protocol operates in ATM networks over PVC and 
  10981.     SVC
  10982.        meshes with the presence of Proxy PAR. These recommendations do not
  10983.        require any protocol changes and allow for simpler, more efficient
  10984.        and cost- effective network designs.  It is recommended that OSPF
  10985.        implementations should be able to support logical interfaces, each
  10986.        consisting of one or more virtual circuits and used as numbered
  10987.        logical point-to-point links (one VC) or logical NBMA networks (more
  10988.        than one VC) where a solution simulating broadcast interfaces is not
  10989.        appropriate.  Proxy PAR can help to distribute configuration changes
  10990.        of such interfaces when OSPF capable routers are reconfigured on the
  10991.        ATM cloud.                                                          
  10992.  
  10993. One Time Password Authentication (otp)
  10994. --------------------------------------
  10995.  
  10996.   "OTP Extended Responses", C. Metz, 09/16/1997, 
  10997.   <draft-ietf-otp-ext-04.txt>                                              
  10998.  
  10999.        This document provides a specification for a type of response to an
  11000.        OTP [RFC 1938] challenge that carries explicit indication of the
  11001.        response's encoding. Codings for the two mandatory OTP data formats
  11002.        using this new type of response are presented.
  11003.     
  11004.        This document also provides a specification for a response that
  11005.        allows an OTP generator to request that a server re-initialize a
  11006.        sequence and change parameters such as the secret pass phrase.      
  11007.  
  11008.   "OTP Verification Examples", P. Nesser, 01/16/1997, 
  11009.   <draft-ietf-otp-ver-01.txt>                                              
  11010.  
  11011.     This document provides a series of inputs and correct outputs for all 
  11012.     three of the defined OTP cryptographic hashes, specifically MD4, MD5, 
  11013.     and SHA1.  This document is intended to be used by developers for 
  11014.     interoperability checks when creating generators or servers.  Output is
  11015.     provided in both hexadecimal notation and the six word encoding 
  11016.     documented in Appendix C.                                              
  11017.  
  11018.   "A One-Time Password System", Neil Haller, P. Nesser, C. Metz, M. Straw, 
  11019.   09/03/1997, <draft-ietf-otp-02.txt>                                      
  11020.  
  11021.     This document describes a one-time password authentication system
  11022.     (OTP). The system provides authentication for system access (login)
  11023.     and other applications requiring authentication that is secure
  11024.     against passive attacks based on replaying captured reusable
  11025.     passwords. OTP evolved from the S/KEY* One-Time Password System that
  11026.     was released by Bellcore and is described in references [3] and [5].   
  11027.  
  11028. Procedures for Internet/Enterprise Renumbering (pier)
  11029. -----------------------------------------------------
  11030.  
  11031.   "IP Addresses in Applications", P. Nesser, 03/25/1997, 
  11032.   <draft-ietf-pier-applications-00.txt>                                    
  11033.  
  11034.     The Procedures for Internet/Enterprise Renumbering (PIER) Working Group
  11035.     of the Internet Engineering Task Force (IETF) has been tasked with the 
  11036.     creation of documents to aid renumbering efforts.  This document 
  11037.     defines a series of classes of IP address locations.  Each class will 
  11038.     be described in a general sense, while specific examples are provided 
  11039.     as possible.                                                           
  11040.  
  11041. Public-Key Infrastructure (X.509) (pkix)
  11042. ----------------------------------------
  11043.  
  11044.   "Internet Public Key Infrastructure   X.509 Certificate and CRL Profile",
  11045.   D. Solo, Russ Housley, Warwick Ford, T. Polk, 10/15/1997, 
  11046.   <draft-ietf-pkix-ipki-part1-06.txt>                                      
  11047.  
  11048.        This is the sixth draft of the Internet Public Key Infrastructure
  11049.        X.509 Certificate and CRL Profile.  This draft is a complete
  11050.        specification.  This text includes minor modifications over the
  11051.        previous draft.  Please send comments on this document to the ietf-
  11052.        pkix@tandem.com mail list.                                          
  11053.  
  11054.   "Internet Public Key Infrastructure     Certificate Management 
  11055.   Protocols", C. Adams, S. Farrell, 10/15/1997, 
  11056.   <draft-ietf-pkix-ipki3cmp-05.txt>                                        
  11057.  
  11058.     This is a draft of the Internet Public Key Infrastructure (X.509)
  11059.     Certificate Management Protocols. Protocol messages are defined for all
  11060.     relevant aspects of certificate creation and management.               
  11061.  
  11062.   "Internet Public Key Infrastructure  Operational Protocols - LDAPv2", Tim
  11063.   Howes, S. Boeyen, P. Richard, 10/23/1997, 
  11064.   <draft-ietf-pkix-ipki2opp-04.txt>                                        
  11065.  
  11066.          The protocol described in this document is designed to satisfy 
  11067.     some
  11068.          of  the  operational  requirements  within  the Internet Public 
  11069.     Key
  11070.          Infrastructure  (IPKI).   Specifically,  this  document   
  11071.     addresses
  11072.          requirements  to  provide access to Public Key Infrastructure 
  11073.     (PKI)
  11074.          repositories for the purposes of  retrieving  PKI  information  
  11075.     and
  11076.          managing  that  same  information.  The mechanism described in 
  11077.     this
  11078.          document is based on  the  Lightweight  Directory  Access  
  11079.     Protocol
  11080.          (LDAP) v2, defined in RFC 1777, defining a profile of that 
  11081.     protocol
  11082.          for use within the IPKI and updates encodings for certificates  
  11083.     and
  11084.          revocation  lists  from  RFC 1778. Additional mechanisms 
  11085.     addressing
  11086.          PKIX operational requirements are specified in separate documents.
  11087.           
  11088.          The key words  'MUST',  'REQUIRED',  'SHOULD',  'RECOMMENDED',  
  11089.     and
  11090.          'MAY'  in  this  document are to be interpreted as described in 
  11091.     RFC
  11092.          2119.
  11093.           
  11094.          Please send comments on this document to  the  
  11095.     ietf-pkix@tandem.com
  11096.          mail list.                                                        
  11097.  
  11098.   "Internet Public Key Infrastructure Certificate Policy and Certification 
  11099.   Practices Framework", Warwick Ford, S. Chokhani, 10/07/1997, 
  11100.   <draft-ietf-pkix-ipki-part4-02.txt>                                      
  11101.  
  11102.     This   document  presents  a  framework  to  assist  the  writers  of
  11103.        certificate  policies  or  certification  practice   statements   
  11104.     for
  11105.        certification   authorities   and  public  key  infrastructures.   
  11106.     In
  11107.        particular, the framework provides a  comprehensive  list  of  
  11108.     topics
  11109.        that potentially (at the writer's discretion) need to be covered in 
  11110.     a
  11111.        certificate policy definition or a certification practice  
  11112.     statement.
  11113.        It is intended that this document, when fully developed, be 
  11114.     published
  11115.        as an Informational RFC.                                            
  11116.  
  11117.   "Internet Public Key Infrastructure Part V:  Time Stamp Protocols", C. 
  11118.   Adams, D. Pinkas, Patrick Cain, Robert Zuccherato, 07/30/1997, 
  11119.   <draft-ietf-pkix-ipki5tsp-00.txt>                                        
  11120.  
  11121.     This document describes the format of the data returned by a Time
  11122.     Stamp Authority and the protocols to be used when communicating with 
  11123.     it.
  11124.     The time stamping service can be used as a Trusted Third Party (TTP) as
  11125.     one component in building reliable non-repudiation services (see
  11126.     [ISONR]).  We also give an example of how to place a signature at a
  11127.     particular point in time, from which the appropriate CRLs may be
  11128.     checked.                                                               
  11129.  
  11130.   "Internet Public Key Infrastructure", C. Adams, Robert Zuccherato, 
  11131.   07/30/1997, <draft-ietf-pkix-ipki6np-00.txt>                             
  11132.  
  11133.     This document describes a general notary service and the protocols to
  11134.     be used when communicating with it.  The Notary Authority is a Trusted
  11135.     Third Party (TTP) that can be used as one component in building 
  11136.     reliable
  11137.     non-repudiation services (see [ISONR]).  We also give an example of how
  11138.     to use the notary to extend the lifetime of a signature beyond key
  11139.     expiry or revocation.                                                  
  11140.  
  11141.   "Internet Public Key Infrastructure   Representation of Key Exchange 
  11142.   Algorithm (KEA) Keys in Internet Public Key Infrastructure Certificates",
  11143.   Russ Housley, William Polk, 10/15/1997, <draft-ietf-pkix-ipki-kea-01.txt>
  11144.  
  11145.     This is the second draft of a profile for specification of Key
  11146.        Exchange Algorithm (KEA) keys in Internet Public Key Infrastructure
  11147.        X.509 certificates. Please send comments on this document to the
  11148.        ietf-pkix@tandem.com mail list.                                     
  11149.  
  11150.   "Internet Public Key Infrastructure Operational Protocols:  FTP and 
  11151.   HTTP", Russ Housley, 10/22/1997, <draft-ietf-pkix-opp-ftp-http-01.txt>   
  11152.  
  11153.        The protocol conventions described in this document satisfy some of
  11154.        the operational requirements of the Internet Public Key
  11155.        Infrastructure (PKI).  This document specifies the conventions for
  11156.        using the File Transfer Protocol (FTP) and the Hypertext Transfer
  11157.        Protocol (HTTP) to obtain certificates and certificate revocation
  11158.        lists (CRLs) from PKI repositories.  Additional mechanisms 
  11159.     addressing
  11160.        PKIX operational requirements are specified in separate documents.
  11161.      
  11162.        Please send comments on this document to the ietf-pkix@tandem.com
  11163.        mail list.                                                          
  11164.  
  11165.   "Internet Public Key Infrastructure Online Certificate Status Protocol - 
  11166.   OCSP", M. Myers, 10/23/1997, <draft-ietf-pkix-ocsp-00.txt>               
  11167.  
  11168.     The protocol conventions described in this document satisfy some of the
  11169.     operational requirements of the Internet Public Key Infrastructure
  11170.     (PKI).  This document specifies an HTTP-based application protocol use-
  11171.     ful in determining the current status of a digital certificate without
  11172.     the use of CRLs.  Additional mechanisms addressing PKIX operational re-
  11173.     quirements are specified in separate documents.
  11174.      
  11175.     Please send comments on this document to the ietf-pkix@tandem.com mail
  11176.     list.                                                                  
  11177.  
  11178. PacketWay (pktway)
  11179. ------------------
  11180.  
  11181.   "The End-to-End (EEP) PacketWay Protocol for High-Performance 
  11182.   Interconnection of Computer Clusters", Danny Cohen, C. Lund, T. Skjellum,
  11183.   T. McMahon, R. George, 10/14/1997, 
  11184.   <draft-ietf-pktway-protocol-eep-spec-02.txt>                             
  11185.  
  11186.     PktWay is an open family of specifications for inter-networking
  11187.     high performance System Area Networks (SANs) and high performance
  11188.     Local Area Networks (LANs) into computing clusters.                    
  11189.  
  11190.   "Part-1 of The Router-to-Router (RRP) PacketWay Protocol for 
  11191.   High-Performance Interconnection of Computer Clusters", Danny Cohen, C. 
  11192.   Lund, T. Skjellum, T. McMahon, R. George, 10/23/1997, 
  11193.   <draft-ietf-pktway-protocol-rrp1-spec-00.txt>                            
  11194.  
  11195.        The PktWay protocol is introduced in the 'The End-to-End (EEP)
  11196.        PacketWay Protocol for High-Performance Interconnection of Computer
  11197.        Clusters'.  This document defines the basic part (Part 1) of the
  11198.        Router-to-Router protocol (RRP) of PacketWay.
  11199.      
  11200.        The shorter 'PktWay' is used for 'PacketWay'.                       
  11201.  
  11202. Process for Organization of Internet StandardS ONg (poisson)
  11203. ------------------------------------------------------------
  11204.  
  11205.   "IETF Working Group Guidelines and Procedures", Scott Bradner, 
  11206.   09/09/1997, <draft-ietf-poisson-wg-guide-01.txt>                         
  11207.  
  11208.     The Internet Engineering Task Force (IETF) has responsibility for
  11209.     developing and reviewing specifications intended as Internet
  11210.     Standards.  IETF activities are organized into working groups (WGs).
  11211.     This document describes the guidelines and procedures for formation
  11212.     and operation of IETF working groups. It also describes the formal
  11213.     relationship between IETF participants WG and the Internet
  11214.     Engineering Steering Group (IESG) and the basic duties of IETF
  11215.     participants, including WG Chairs, WG participants, and IETF Area
  11216.     Directors.                                                             
  11217.  
  11218.   "IAB and IESG Selection, Confirmation, and Recall Process:  Operation of 
  11219.   the Nominating and Recall Committees", James Galvin, 08/02/1997, 
  11220.   <draft-ietf-poisson-nomcom-02.txt>                                       
  11221.  
  11222.        The process by which the members of the IAB and IESG are selected,
  11223.        confirmed, and recalled is specified.  The evolution of the process
  11224.        has relied principally on oral tradition as a means by which the
  11225.        lessons learned could be passed on to successive committees.  This
  11226.        document is a self-consistent, organized compilation of the process
  11227.        as it is known today.                                               
  11228.  
  11229. Point-to-Point Protocol Extensions (pppext)
  11230. -------------------------------------------
  11231.  
  11232.   "PPP Hewlett-Packard Packet-by-Packet Compression (HP PPC) Protocol", J. 
  11233.   Petty, 10/29/1993, <draft-ietf-pppext-hpppc-00.txt>                      
  11234.  
  11235.     The Point-to-Point Protocol (PPP) provides a standard method for 
  11236.     transporting multi-protocol datagrams over point-to-point links.       
  11237.     The PPP Compression Control Protocol provides a method to negotiate and
  11238.     utilize compression protocols over PPP encapsulated links.             
  11239.     This document describes the use of the HP PPC compression algorithm for
  11240.     compressing PPP encapsulated packets.                                  
  11241.  
  11242.   "The PPP Internet Protocol Control Protocol (IPCP)", G. McGregor, 
  11243.   03/21/1997, <draft-ietf-pppext-ipcp-network-01.txt>                      
  11244.  
  11245.     The Point-to-Point Protocol (PPP) [1] provides a standard method of 
  11246.     encapsulating Network Layer protocol information over point-to-point 
  11247.     links.  PPP also defines an extensible Link Control Protocol, and 
  11248.     proposes a family of Network Control Protocols (NCPs) for establishing 
  11249.     and configuring different network-layer protocols.                     
  11250.     This document defines the NCP for establishing and configuring the 
  11251.     Internet Protocol [2] over PPP, and a method to negotiate and use Van 
  11252.     Jacobson TCP/IP header compression [3] with PPP.                       
  11253.  
  11254.   "PPP Extensible Authentication Protocol (EAP)", J. Vollbrecht, Larry 
  11255.   Blunk, 07/23/1996, <draft-ietf-pppext-eap-auth-02.txt>                   
  11256.  
  11257.     The Point-to-Point Protocol (PPP) [1] provides a standard method for 
  11258.     transporting multi-protocol datagrams over point-to-point links.       
  11259.     PPP also defines an extensible Link Control Protocol, which allows 
  11260.     negotiation of an Authentication Protocol for authenticating its peer 
  11261.     before allowing Network Layer protocols to transmit over the link.     
  11262.     This document defines the PPP Extensible Authentication Protocol.      
  11263.  
  11264.   "PPP EAP RSA Public Key Authentication Protocol", W. Whelan, 02/20/1997, 
  11265.   <draft-ietf-pppext-eaprsa-04.txt>                                        
  11266.  
  11267.     The Point-to-Point Protocol (PPP) [1] provides a standard method for 
  11268.     transporting multi-protocol datagrams over point-to-point links.       
  11269.     PPP also defines an extensible Link Control Protocol, which allows 
  11270.     negotiation of an Authentication Protocol for authentication its peer 
  11271.     before allowing Network Layer protocols to transmit over the link.     
  11272.     PPP Extensible Authentication Protocol (EAP) [2] provides for a number 
  11273.     of authentication mechanisms.  One of these is RSA Public Key 
  11274.     Authentication.  This document defines RSA Public Key Authentication 
  11275.     Protocol within PPP EAP.                                               
  11276.  
  11277.   "PPP LCP Extensions", W. Simpson, 07/28/1997, 
  11278.   <draft-ietf-pppext-lcpext-ds-02.txt>                                     
  11279.  
  11280.     The Point-to-Point Protocol (PPP) [1] provides a standard method for 
  11281.     transporting multi-protocol datagrams over point-to-point links.  PPP 
  11282.     defines an extensible Link Control Protocol (LCP) for establishing, 
  11283.     configuring, and testing the data-link connection.  This document 
  11284.     defines additional LCP features that have been suggested over the past 
  11285.     few years.                                                             
  11286.  
  11287.   "Point-to-Point Tunneling Protocol--PPTP", G. Pall, K. Hamzeh, W. 
  11288.   Verthein, J. Taarud, W. Little, 07/24/1997, 
  11289.   <draft-ietf-pppext-pptp-02.txt>                                          
  11290.  
  11291.     This document specifies a protocol which allows the Point to Point 
  11292.     Protocol (PPP) to be tunneled through an IP network. PPTP does not 
  11293.     specify any changes to the PPP protocol but rather describes a new 
  11294.     vehicle for carrying PPP. A client-server architecture is defined in 
  11295.     order to decouple functions which exist in current Network Access 
  11296.     Servers (NAS) and support Virtual Private Networks (VPNs). The PPTP 
  11297.     Network Server (PNS) is envisioned to run on a general purpose 
  11298.     operating system while the client, referred to as a PPTP Access 
  11299.     Concentrator (PAC) operates on a dial access platform. PPTP specifies a
  11300.     call-control and management protocol which allows the server to control
  11301.     access for dial-in circuit switched calls originating from a PSTN or 
  11302.     ISDN or to initiate outbound circuit-switched connections. PPTP uses a 
  11303.     GRE-like (Generic Routing Encapsulation) mechanism to provide a flow- 
  11304.     and congestion-controlled encapsulated datagram service for carrying 
  11305.     PPP packets.                                                           
  11306.  
  11307.   "Layer Two Tunneling Protocol 'L2TP'", William Palter, T. Kolar, G. Pall,
  11308.   M. Littlewood, A. Valencia, K. Hamzeh, W. Verthein, J. Taarud, W. Mark 
  11309.   Townsley, 10/21/1997, <draft-ietf-pppext-l2tp-07.txt>                    
  11310.  
  11311.         Virtual dial-up allows many separate and autonomous protocol 
  11312.     domains
  11313.        to share common access infrastructure including modems, Access
  11314.        Servers, and ISDN routers.  RFC1661 specifies multiprotocol dial-up
  11315.        via PPP [1].  This document describes the Layer Two Tunneling
  11316.        Protocol (L2TP) which permits the tunneling of the link layer (i.e.,
  11317.        HDLC, async HDLC) of PPP.  Using such tunnels, it is possible to
  11318.        divorce the location of the initial dial-up server from the location
  11319.        at which the dial-up protocol connection is terminated and access to
  11320.        the network provided.                                               
  11321.  
  11322.   "Mobile-IPv4 Configuration Option for PPP IPCP", Jim Solomon, S. Glass, 
  11323.   07/02/1997, <draft-ietf-pppext-ipcp-mip-02.txt>                          
  11324.  
  11325.     Mobile IP [RFC 2002] defines media-independent procedures by which a 
  11326.     Mobile Node can maintain existing transport and application-layer 
  11327.     connections despite changing its point-of-attachment to the Internet 
  11328.     and without changing its IP address.  PPP [RFC 1661] provides a 
  11329.     standard method for transporting multi-protocol packets over 
  11330.     point-to-point links.  As currently specified, Mobile IP Foreign Agents
  11331.     which support Mobile Node connections via PPP can do so only by first 
  11332.     assigning unique addresses to those Mobile Nodes, defeating one of the 
  11333.     primary advantages of Foreign Agents.  This documents corrects this 
  11334.     problem by defining the Mobile-IPv4 Configuration Option to the 
  11335.     Internet Protocol Control Protocol (IPCP) [RFC 1332].  Using this 
  11336.     option, two peers can communicate their support for Mobile IP during 
  11337.     the IPCP phase of PPP.  Familiarity with Mobile IP [RFC 2002], IPCP 
  11338.     [RFC 1332], and PPP [RFC 1661] is assumed.                             
  11339.  
  11340.   "Semi Connected Mode for PPP links", M. Latvala, G. Liu, 03/14/1997, 
  11341.   <draft-ietf-pppext-scm-00.txt>                                           
  11342.  
  11343.     The configuration of a Point-to-Point Protocol (PPP) [1] link requires 
  11344.     a considerable amount of time which makes it impractical to establish a
  11345.     new PPP link every time an end-user wants to send or is about to 
  11346.     receive data. This document proposes an LCP extension called Semi 
  11347.     Connected Mode.        When both sides agree to use Semi Connected Mode
  11348.     they can terminate and quickly re-establish the bearer service without 
  11349.     having to reconfigure the PPP link.                                    
  11350.  
  11351.   "Proposal for a PPP Network Layer Entity Selection Protocol", A. Doria, 
  11352.   X. Chen, 03/26/1997, <draft-ietf-pppext-nles-00.txt>                     
  11353.  
  11354.     With the introduction of xDSL services into public  telecommunications 
  11355.     networks, direct access (in contrast to dial-up access) will start to 
  11356.     be used as an access method for data  as  well  as  other services.   
  11357.     PPP  has been very successful in providing connections for IP as well 
  11358.     as other protocols in the dial-up  access  network. With  the advent of
  11359.     direct access, changes will be need to be made for identifying the 
  11360.     target hosts, as it will no longer be possible to rely on the telephone
  11361.     number that is dialed prior to initiating the PPP session.  This 
  11362.     proposal indicates one method for  adapting PPP to the new 
  11363.     requirements.                                                          
  11364.  
  11365.   "PPP over AAL5", M. Kaycee, A. Malis, A. Lin, J. Stephens, G. Gross, 
  11366.   09/30/1997, <draft-ietf-pppext-aal5-02.txt>                              
  11367.  
  11368.          The Point-to-Point Protocol (PPP) [1] provides a standard method
  11369.          for transporting multi-protocol datagrams over point-to-point
  11370.          links.
  11371.      
  11372.          This document describes the use of ATM Adaptation Layer 5 (AAL5)
  11373.          for framing PPP encapsulated packets.                             
  11374.  
  11375.   "Layer Two Tunneling Protocol (L2TP) over AAL5 and FUNI", M. Kaycee, N. 
  11376.   Arunkumar, A. Lin, T. Kwok, 03/27/1997, 
  11377.   <draft-ietf-pppext-l2tp-aal5-funi-00.txt>                                
  11378.  
  11379.     Layer Two Tunneling Protocol describes a mechanism to tunnel PPP 
  11380.     sessions.  The protocol has been designed to be independent of the 
  11381.     media it runs over. The base specification describes how it should be 
  11382.     implemented to run over UDP and IP.  This document describes how the 
  11383.     Layer Two Tunneling Protocol MUST be implemented over ATM (AAL5 and 
  11384.     FUNI).                                                                 
  11385.  
  11386.   "PPP LCP CallBack", W. Simpson, 07/30/1997, 
  11387.   <draft-ietf-pppext-callback-ds-01.txt>                                   
  11388.  
  11389.        The Point-to-Point Protocol (PPP) [1] provides a standard method for
  11390.        transporting multi-protocol datagrams over point-to-point links.  
  11391.     PPP
  11392.        defines an extensible Link Control Protocol (LCP) for establishing,
  11393.        configuring, and testing the data-link connection.  This document
  11394.        defines the CallBack option.
  11395.                                                                            
  11396.  
  11397.   "Layer Two Tunneling Protocol 'L2TP' Security Extensions for Non-IP 
  11398.   networks", Pat Calhoun, W. Mark Townsley, 10/10/1997, 
  11399.   <draft-ietf-pppext-l2tp-sec-02.txt>                                      
  11400.  
  11401.     The L2TP document [1] defines the base protocol  which  describes  the
  11402.     method  of  tunneling  PPP [2] data. The L2TP document states that the 
  11403.     security mechanism used over an IP network is to use the IETF's  IPSEC 
  11404.     protocols.
  11405.      
  11406.     L2TP was designed in such a  way  as  to  be  able  to  run  over  any 
  11407.     underlying   layer  (i.e.  Frame  Relay,  ATM,  etc.).  This  document 
  11408.     specifies  extensions  to  the  L2TP  protocol  in  order  to  provide
  11409.     authentication  and  integrity  of  individual  packets  in a tunneled
  11410.     session over a  network  where  IPSEC  or  another  suitable  security
  11411.     protocol is not available.                                             
  11412.  
  11413.   "The PPP DES Encryption Protocol, Version 2 (DESE-bis)", Keith Sklower, 
  11414.   G. M. Meyer, 07/15/1997, <draft-ietf-pppext-des-encrypt-v2-00.txt>       
  11415.  
  11416.     The Point-to-Point Protocol (PPP) [1] provides a standard method for 
  11417.     transporting multi-protocol datagrams over point-to-point links.       
  11418.     The PPP Encryption Control Protocol (ECP) [2] provides a method to 
  11419.     negotiate and utilize encryption protocols over PPP encapsulated links.
  11420.     This document provides specific details for the use of the DES standard
  11421.     [5, 6] for encrypting PPP encapsulated packets.                        
  11422.  
  11423.   "The PPP Triple-DES Encryption Protocol (3DESE)", H. Kummert, 07/21/1997,
  11424.   <draft-ietf-pppext-3des-encrypt-00.txt>                                  
  11425.  
  11426.     The Point-to-Point Protocol (PPP) [1] provides a standard method for 
  11427.     transporting multi-protocol datagrams over point-to-point links.       
  11428.     The PPP Encryption Control Protocol (ECP) [2] provides a method to 
  11429.     negotiate and utilize encryption protocols over PPP encapsulated links.
  11430.     This document provides specific details for the use of the Triple-DES 
  11431.     standard (3DES) [6] for encrypting PPP encapsulated packets.           
  11432.  
  11433.   "PPP Over FUNI", M. Kaycee, A. Malis, A. Lin, J. Stephens, G. Gross, 
  11434.   09/30/1997, <draft-ietf-pppext-funi-02.txt>                              
  11435.  
  11436.          The Point-to-Point Protocol (PPP) [1] provides a standard method
  11437.          for transporting multi-protocol datagrams over point-to-point
  11438.          links.
  11439.      
  11440.          This document describes the use of ATM Frame User Network 
  11441.     Interface
  11442.          (FUNI)  for framing PPP encapsulated packets.                     
  11443.  
  11444.   "PPP LCP Self Describing Padding", W. Simpson, 07/29/1997, 
  11445.   <draft-ietf-pppext-padding-ds-00.txt>                                    
  11446.  
  11447.        The Point-to-Point Protocol (PPP) [1] provides a standard method for
  11448.        transporting multi-protocol datagrams over point-to-point links.  
  11449.     PPP
  11450.        defines an extensible Link Control Protocol (LCP) for establishing,
  11451.        configuring, and testing the data-link connection.  This document
  11452.        defines several additional LCP features that have been suggested 
  11453.     over
  11454.        the past few years.
  11455.     
  11456.                                                                            
  11457.  
  11458.   "Layer Two Tunneling Protocol 'L2TP' Management Information Base", Pat 
  11459.   Calhoun, Ross Wheeler, Gayam Reddy, 10/10/1997, 
  11460.   <draft-ietf-pppext-l2tp-mib-00.txt>                                      
  11461.  
  11462.        This memo defines a portion of the Management Information  Base  
  11463.     (MIB)
  11464.        for  use  with network management protocols in TCP/IP-based 
  11465.     internets.
  11466.        In particular, it defines objects for managing networks using Layer 
  11467.     2
  11468.        Tunneling Protocol.
  11469.      
  11470.        This memo specifies a MIB module in a manner that is both compliant 
  11471.     to
  11472.        the  SNMPv2  SMI,  and  semantically  identical  to  the  peer  
  11473.     SNMPv1
  11474.        definitions.                                                        
  11475.  
  11476.   "PPP EAP TLS Authentication Protocol", B. Aboba, D. Simon, 10/21/1997, 
  11477.   <draft-ietf-pppext-eaptls-02.txt>                                        
  11478.  
  11479.          The  Point-to-Point  Protocol  (PPP)  provides  a  standard method
  11480.     for
  11481.          transporting multi-protocol datagrams over point-to-point links.  
  11482.     PPP
  11483.          also  defines  an extensible Link Control Protocol (LCP), which 
  11484.     can be
  11485.          used to negotiate authentication methods, as  well  as  an  
  11486.     Encryption
  11487.          Control  Protocol  (ECP),  used  to negotiate data encryption over
  11488.     PPP
  11489.          links, and a Compression Control Protocol  (CCP),  used  to  
  11490.     negotiate
  11491.          compression  methods.  The Extensible Authentication Protocol 
  11492.     (EAP) is
  11493.          a PPP extension that provides support  for  additional  
  11494.     authentication
  11495.          methods within PPP.
  11496.      
  11497.          Transport  Level  Security  (TLS)  provides for mutual 
  11498.     authentication,
  11499.          integrity-protected ciphersuite negotiation and key  exchange  
  11500.     between
  11501.          two  endpoints.   This  document describes how EAP-TLS, which 
  11502.     includes
  11503.          support for fragmentation and reassembly, provides for these TLS 
  11504.     mech-
  11505.          anisms within EAP.                                                
  11506.  
  11507.   "PPP over SONET/SDH",, 10/16/1997, 
  11508.   <draft-ietf-pppext-pppsonet-scrambler-00.txt>                            
  11509.  
  11510.     This Internet Draft addresses the PPP/SONET interface defined
  11511.     in the IETF RFC 1619 and its application in public Internet backbone
  11512.     networks. By experimental analysis it is found that this SONET 
  11513.     interface
  11514.     specification is deficient in providing payload transparency. This
  11515.     deficiency leads to deleterious effects in providing reliable network
  11516.     operations. A simple SONET payload scrambler enhancement is proposed to
  11517.     overcome this deficiency. This work has been brought to the
  11518.     ANSI T1X1.5 as an action item for the addition of the RFC 1619 mapping
  11519.     to T1.105 with a scrambler to be determined by T1X1.
  11520.      
  11521.     We are submitting the same proposal to IETF now with the interest to
  11522.     enhance RFC-1619 accordingly and achieve alignment with ANSI T1 
  11523.     standards.
  11524.     To facilitate this alignment, we have recommended that T1X1 establish a
  11525.     formal liaison with IETF in regard to IP/SONET interface standards
  11526.     and associated IP transmission standards development.                  
  11527.  
  11528. Printer MIB (printmib)
  11529. ----------------------
  11530.  
  11531.   "Printer MIB", R. Turner, 10/16/1997, 
  11532.   <draft-ietf-printmib-mib-info-03.txt>                                    
  11533.  
  11534.     This document provides definitions of models and manageable
  11535.               objects for printing environments. The objects included in 
  11536.     this
  11537.               MIB apply to physical, as well as logical entities within a
  11538.               printing device. This MIB definition makes explicit 
  11539.     references to
  11540.               the Host Resources MIB (RFC 1514), as well as the Interfaces
  11541.               Group of MIB-II (RFC 1213).                                  
  11542.  
  11543.   "Job Monitoring MIB - V0.85", T. Hasting, H. Lewis, S. Isaacson, R. 
  11544.   Bergman, 09/26/1997, <draft-ietf-printmib-job-monitor-06.txt>            
  11545.  
  11546.          This Internet-Draft specifies a small set of read-only SNMP MIB
  11547.          objects for (1) monitoring the status and progress of print jobs
  11548.          (2) obtaining resource requirements before a job is processed, (3)
  11549.          monitoring resource consumption while a job is being processed and
  11550.          (4) collecting resource accounting data after the completion of a
  11551.          job.  This MIB is intended to be implemented (1) in a printer or
  11552.          (2) in a server that supports one or more printers.  Use of the
  11553.          object set is not limited to printing.  However, support for
  11554.          services other than printing is outside the scope of this Job
  11555.          Monitoring MIB.  Future extensions to this MIB may include, but 
  11556.     are
  11557.          not limited to, fax machines and scanners.                        
  11558.  
  11559. Physical Topology MIB (ptopomib)
  11560. --------------------------------
  11561.  
  11562.   "Physical Topology MIB", Ken Jones, Andy Bierman, 09/22/1997, 
  11563.   <draft-ietf-ptopomib-mib-01.txt>                                         
  11564.  
  11565.     This memo defines an experimental portion of the Management Information
  11566.     Base (MIB) for use with network management protocols in the Internet
  11567.     community.  In particular, it describes managed objects used for
  11568.     managing physical topology identification and discovery.               
  11569.  
  11570.   "Physical Topology Discovery Protocol and MIB", Keith McCloghrie, Andy 
  11571.   Bierman, 09/17/1997, <draft-ietf-ptopomib-pdp-01.txt>                    
  11572.  
  11573.     This memo defines an experimental protocol, and an experimental portion
  11574.     of the Management Information Base (MIB) for use with network 
  11575.     management
  11576.     protocols in the Internet community.  In particular, it describes a
  11577.     physical topology discovery protocol and managed objects used for
  11578.      
  11579.                                                                            
  11580.  
  11581. QoS Routing (qosr)
  11582. ------------------
  11583.  
  11584.   "A Framework for QoS-based Routing in the Internet", R. Nair, B. 
  11585.   Rajagopalan, Hal Sandick, Eric Crawley, 07/30/1997, 
  11586.   <draft-ietf-qosr-framework-01.txt>                                       
  11587.  
  11588.     QoS-based routing is being recognized as the missing piece in the 
  11589.     evolution
  11590.     of QoS-based service offerings in the Internet. This document describes
  11591.     some of the QoS-based routing issues and requirements, and proposes
  11592.     a framework for QoS-based routing in the Internet. This framework is 
  11593.     based
  11594.     on extending the current Internet routing model of intra and
  11595.     interdomain routing to support QoS. The ideas expressed in this 
  11596.     document
  11597.     are subject to discussion and expected to evolve based on inputs
  11598.     received over time.                                                    
  11599.  
  11600. Remote Authentication Dial-In User Service (radius)
  11601. ---------------------------------------------------
  11602.  
  11603.   "Implementation of PPTP/L2TP Compulsory Tunneling via RADIUS", B. Aboba, 
  11604.   G. Zorn, 07/28/1997, <draft-ietf-radius-tunnel-imp-03.txt>               
  11605.  
  11606.     This document discusses implementation issues arising in the 
  11607.     provisioning of compulsory tunneling in dial-up networks using the PPTP
  11608.     and L2TP protocols.  This provisioning can be accomplished via the 
  11609.     integration of RADIUS and tunneling protocols.  Implementation issues 
  11610.     encountered with other tunneling protocols are left to separate 
  11611.     documents.                                                             
  11612.  
  11613.   "RADIUS Attributes for Tunnel Protocol Support", J. Shriver, D. Leifer, 
  11614.   G. Zorn, 08/05/1997, <draft-ietf-radius-tunnel-auth-02.txt>              
  11615.  
  11616.     This document defines a set of RADIUS attributes designed to support 
  11617.     the
  11618.     provision   of   compulsory   tunneling  in  dial-up  networks.   
  11619.     RADIUS
  11620.     attributes for both authorization and accounting are specified.        
  11621.  
  11622.   "Extensible Authentication Protocol Support in RADIUS", Allan Rubens, B. 
  11623.   Aboba, Pat Calhoun, 05/22/1997, <draft-ietf-radius-eap-02.txt>           
  11624.  
  11625.     The Extensible Authentication Protocol (EAP) is a PPP extension that 
  11626.     provides support for additional authentication methods within PPP.  
  11627.     This document describes how the EAP-Message and Signature attributes 
  11628.     may be used for providing EAP support within RADIUS.                   
  11629.  
  11630.   "RADIUS Extensions", Carl Rigney, W. Willats, 01/22/1997, 
  11631.   <draft-ietf-radius-ext-00.txt>                                           
  11632.  
  11633.     This document describes additional attributes for carrying 
  11634.     authentication, authorization and accounting information between a 
  11635.     Network Access Server (NAS) and a shared Accounting Server using the 
  11636.     Remote Authentication Dial In User Service (RADIUS) protocol described 
  11637.     in RFC 2058 and RFC 2059.                                              
  11638.  
  11639.   "RADIUS Accounting Interim Accounting Record Extension", A. Ratcliffe, 
  11640.   Pat Calhoun, M. Beadles, 07/02/1997, 
  11641.   <draft-ietf-radius-acct-interim-00.txt>                                  
  11642.  
  11643.     The RADIUS Accounting document [1] defines a mechanism which is used by
  11644.     a Network Access Server (NAS) to send accounting information to a 
  11645.     RADIUS server. The current protocol defines a Start and Stop record. 
  11646.     This document defines an interim record which is used to make the 
  11647.     RADIUS accounting protocol more robust.                                
  11648.  
  11649.   "RADIUS Authentication Server MIB", B. Aboba, G. Zorn, 08/26/1997, 
  11650.   <draft-ietf-radius-auth-servmib-00.txt>                                  
  11651.  
  11652.     This  memo defines a set of extensions which instrument RADIUS 
  11653.     authentication server functions. These extensions represent a portion 
  11654.     of the Management Information Base (MIB) for use with network 
  11655.     management protocols in the Internet community.   Using  these  
  11656.     extensions  IP-based management stations can manage RADIUS 
  11657.     authentication servers.                                                
  11658.  
  11659.   "RADIUS Accounting Client MIB", B. Aboba, G. Zorn, 08/26/1997, 
  11660.   <draft-ietf-radius-acc-clientmib-00.txt>                                 
  11661.  
  11662.     This memo defines a set of extensions which instrument RADIUS 
  11663.     accounting 
  11664.     client functions. These extensions represent a portion of the 
  11665.     Management Information Base (MIB) for use with network management 
  11666.     protocols 
  11667.     in the Internet community.  Using these extensions IP-based management 
  11668.     stations can manage RADIUS accounting clients.                         
  11669.  
  11670.   "RADIUS Accounting Server MIB", B. Aboba, G. Zorn, 08/26/1997, 
  11671.   <draft-ietf-radius-acc-servmib-00.txt>                                   
  11672.  
  11673.     This memo defines a set of extensions which instrument RADIUS 
  11674.     accounting server functions. These extensions represent a portion of 
  11675.     the Management Information Base (MIB) for use with network management 
  11676.     protocols in the Internet community.  Using these extensions IP-based  
  11677.     management stations can manage RADIUS accounting servers.
  11678.      
  11679.                                                                            
  11680.  
  11681.   "RADIUS Authentication Client MIB", B. Aboba, G. Zorn, 08/26/1997, 
  11682.   <draft-ietf-radius-auth-clientmib-00.txt>                                
  11683.  
  11684.     This  memo defines a set of extensions which instrument RADIUS 
  11685.     authentication client functions. These extensions represent a 
  11686.     portion of the Management Information Base (MIB) for use with network 
  11687.     management protocols in the Internet community.   Using these  
  11688.     extensions  IP-based management stations can manage RADIUS 
  11689.     authentication clients.
  11690.      
  11691.                                                                            
  11692.  
  11693.   "RADIUS Attributes for MS-CHAP Support", G. Zorn, 10/23/1997, 
  11694.   <draft-rfced-info-zorn-00.txt>                                           
  11695.  
  11696.     This document describes  a  set  of  vendor-specific  RADIUS  
  11697.     attributes
  11698.     designed  to  support  the use of Microsoft's proprietary dialect of 
  11699.     PPP
  11700.     CHAP (MS-CHAP) in dial-up networks.  MS-CHAP is derived from and  
  11701.     (where
  11702.     possible) consistent with PPP CHAP [1]; the differences between PPP 
  11703.     CHAP
  11704.     and MS-CHAP are significant enough to  warrant  the  definition  of  
  11705.     new
  11706.     RADIUS attributes, however.                                            
  11707.  
  11708. Receipt Notifications for Internet Mail (receipt)
  11709. -------------------------------------------------
  11710.  
  11711.   "An Extensible Message Format for Message Disposition Notifications", 
  11712.   Roger Fajman, 10/23/1997, <draft-ietf-receipt-mdn-06.txt>                
  11713.  
  11714.     This memo defines a MIME content-type that may be used by a mail
  11715.     user agent (UA) or electronic mail gateway to report the disposition
  11716.     of a message after it has been sucessfully delivered to a recipient.
  11717.     This content-type is intended to be machine-processable.  Additional
  11718.     message headers are also defined to permit Message Disposition
  11719.     Notifications (MDNs) to be requested by the sender of a message.
  11720.     The purpose is to extend Internet Mail to support functionality
  11721.     often found in other messaging systems, such as X.400 and the
  11722.     proprietary 'LAN-based' systems, and often referred to as 'read
  11723.     receipts,' 'acknowledgements,' or 'receipt notifications.'  The
  11724.     intention is to do this while respecting the privacy concerns that have
  11725.     often been expressed when such functions have been discussed in
  11726.     the past.
  11727.      
  11728.     Because many messages are sent between the Internet and other
  11729.     messaging systems (such as X.400 or the proprietary 'LAN-based'
  11730.     systems), the MDN protocol is designed to be useful in a multi-
  11731.     protocol messaging environment.  To this end, the protocol described
  11732.     in this memo provides for the carriage of 'foreign' addresses, in
  11733.     addition to those normally used in Internet Mail.  Additional
  11734.     attributes may also be defined to support 'tunneling' of foreign
  11735.     notifications through Internet Mail.                                   
  11736.  
  11737. Routing Information Protocol (rip)
  11738. ----------------------------------
  11739.  
  11740.   "RIP Version 2 MIB Extension", G. Malkin, Fred Baker, 03/20/1997, 
  11741.   <draft-ietf-rip-mib-00.txt>                                              
  11742.  
  11743.     This memo defines a portion of the Management Information Base (MIB) 
  11744.     for use with network management protocols in TCP/IP-based internets. In
  11745.     particular, it defines objects for managing RIP Version 2.             
  11746.  
  11747.   "RIPv2 Domain Of Interpretation (DOI) for ISAKMP", Ran Atkinson, 
  11748.   10/16/1997, <draft-ietf-rip-doi-00.txt>                                  
  11749.  
  11750.           The Internet Security  Association  and  Key  Management  
  11751.     Protocol
  11752.        (ISAKMP)  defines a framework for security association management 
  11753.     and
  11754.        cryptographic key establishment for  the  Internet.   This  
  11755.     framework
  11756.        consists  of  defined  exchanges and processing guidelines that 
  11757.     occur
  11758.        within a given Domain of Interpretation (DOI).  This document 
  11759.     details
  11760.        the  RIPv2  DOI,  which  is  defined  to  cover  the use of ISAKMP 
  11761.     to
  11762.        negotiate Security Associations for the RIPv2 routing protocol.     
  11763.  
  11764. RIP Version II (ripv2)
  11765. ----------------------
  11766.  
  11767.   "RIP Version 2 Carrying Additional Information", G. Malkin, 03/25/1997, 
  11768.   <draft-ietf-ripv2-protocol-v2-02.txt>                                    
  11769.  
  11770.     This document specifies an extension of the Routing Information 
  11771.     Protocol (RIP), as defined in [1], to expand the amount of useful 
  11772.     information carried in RIP messages and to add a measure of security.  
  11773.     A companion document will define the SNMP MIB objects for RIP-2 [2].  
  11774.     An additional document will define cryptographic security improvements 
  11775.     for RIP-2 [3].                                                         
  11776.  
  11777.   "RIP-II MD5 Authentication", Fred Baker, Ran Atkinson, 03/07/1997, 
  11778.   <draft-ietf-ripv2-md5-auth-00.txt>                                       
  11779.  
  11780.     Growth in the Internet has made us aware of the need for improved 
  11781.     authentication of routing information.  RIP-II provides for 
  11782.     unauthenticated service (as in classical RIP), or password 
  11783.     authentication.  Both are vulnerable to passive attacks currently 
  11784.     widespread in the Internet.  Well-understood security issues exist in 
  11785.     routing protocols [4].  Clear text passwords, currently specified for 
  11786.     use with RIP-II, are no longer considered sufficient [5].              
  11787.  
  11788. Remote Network Monitoring (rmonmib)
  11789. -----------------------------------
  11790.  
  11791.   "Remote Network Monitoring MIB Extensions for Switch Networks           
  11792.   Version 1.0", Steven Waldbusser, Dan Romascanu, W. Lahaye, R. Waterman, 
  11793.   10/23/1997, <draft-ietf-rmonmib-smon-04.txt>                             
  11794.  
  11795.     This memo defines a portion of the Management Information Base (MIB)
  11796.        for use with network management protocols in TCP/IP-based internets.
  11797.        In particular, it defines objects for managing remote network
  11798.        monitoring devices in switched networks environments.               
  11799.  
  11800.   "Remote Network Monitoring MIB Protocol Identifiers (Version 2)", C. 
  11801.   Bucci, R. Iddon, Andy Bierman, 10/29/1997, 
  11802.   <draft-ietf-rmonmib-rmonprot-v2-03.txt>                                  
  11803.  
  11804.     This memo describes protocol encapsulations which are referenced by the
  11805.     management objects defined in the Remote Network Monitoring MIB Version
  11806.     2 [RFC2021].  Additionally, this memo defines a notation describing
  11807.     protocol layers in a protocol encapsulation and contains a large list 
  11808.     of
  11809.     protocol definitions using this notation.  Although related to the
  11810.     original Remote Network Monitoring MIB [RFC1757], this document refers
  11811.     only to objects found in the RMON-2 MIB.                               
  11812.  
  11813.   "Remote Network Monitoring Management Information Base for High Capacity 
  11814.   Networks", Steven Waldbusser, 09/19/1997, 
  11815.   <draft-ietf-rmonmib-hcrmon-02.txt>                                       
  11816.  
  11817.     This memo defines an experimental portion of the Management
  11818.     Information Base (MIB) for use with network management
  11819.     protocols in TCP/IP-based internets.  In particular, it
  11820.     defines objects for managing remote network monitoring       
  11821.     devices.
  11822.      
  11823.     This memo does not specify a standard for the Internet
  11824.     community.                                                             
  11825.  
  11826. Roaming Operations (roamops)
  11827. ----------------------------
  11828.  
  11829.   "Dialup Roaming Requirements", B. Aboba, G. Zorn, 07/11/1997, 
  11830.   <draft-ietf-roamops-roamreq-05.txt>                                      
  11831.  
  11832.     This document describes the features required for the provision of 
  11833.     'roaming capability' for dialup Internet users, as well as offering 
  11834.     some suggestions for future protocol standardization work.  'Roaming 
  11835.     capability' is defined as the ability to use any one of multiple 
  11836.     Internet service providers (ISPs), while maintaining a formal, 
  11837.     customer-vendor relationship with only one.  Examples of cases where 
  11838.     roaming capability might be required include ISP 'confederations' and 
  11839.     ISP-provided corporate network access support.                         
  11840.  
  11841.   "The Network Access Identifier", B. Aboba, M. Beadles, 09/09/1997, 
  11842.   <draft-ietf-roamops-nai-07.txt>                                          
  11843.  
  11844.     In order to enhance the interoperability of roaming and tunneling 
  11845.     services, it is desirable to have a standardized method for identifying
  11846.     users.  This  document proposes syntax for the Network Access 
  11847.     Identifier (NAI). It is expected that this will be of interest for 
  11848.     support of roaming as well as tunneling.  'Roaming capability' may be 
  11849.     loosely defined as the ability to use any one of multiple Internet 
  11850.     service providers (ISPs),  while maintaining a formal, customer-vendor 
  11851.     relationship with only one.  Examples of cases where roaming capability
  11852.     might be required include ISP 'confederations' and ISP-provided 
  11853.     corporate network access support.                                      
  11854.  
  11855.   "Session Record Accounting in Roaming", J. Vollbrecht, B. Aboba, D. 
  11856.   Lidyard, 08/26/1997, <draft-ietf-roamops-actng-03.txt>                   
  11857.  
  11858.     This  document describes the problems arising in session record
  11859.     accounting in roaming systems,  and proposes a standard accounting 
  11860.     record format.                                                         
  11861.  
  11862.   "Guidelines for the Operation of RADIUS Proxies in Roaming", J. 
  11863.   Vollbrecht, B. Aboba, G. Zorn, 09/10/1997, 
  11864.   <draft-ietf-roamops-auth-03.txt>                                         
  11865.  
  11866.     Today, while RADIUS proxy chaining is widely deployed for the purposes 
  11867.     of providing roaming services, interoperation between roaming  systems 
  11868.     is difficult.  This document provides guidelines for the operation of 
  11869.     RADIUS proxies within roaming systems.                                 
  11870.  
  11871.   "Secure Radius Server Operation Guidelines for Dial Roaming
  11872.   ", Y. Jiang, 10/21/1997, <draft-ietf-roamops-sec-00.txt>                 
  11873.  
  11874.       Authenticating and authorizing roaming dialup users requires
  11875.       messages to be exchanged among facilities managed by two or
  11876.       more service providers, and secure operation of the facilities
  11877.       is of vital importance.  This document provides guidelines for
  11878.       operating such facilities when using the Remote Authentication
  11879.       Dial In User Service (RADIUS) protocol and the companion
  11880.       accounting protocol for authentication and accounting message
  11881.       exchange.                                                            
  11882.  
  11883. Routing Policy System (rps)
  11884. ---------------------------
  11885.  
  11886.   "Routing Policy Specification Language (RPSL)", Daniel Karrenberg, D. 
  11887.   Meyer, M. Terpstra, C. Villamizar, Cengiz Alaettinoglu, T. Bates, 
  11888.   08/02/1997, <draft-ietf-rps-rpsl-03.txt,.ps>                             
  11889.  
  11890.     This Internet Draft is the reference document for the Routing Policy 
  11891.     Specification Language (RPSL). RPSL allows a network operator to be 
  11892.     able to specify routing policies at various levels in the Internet 
  11893.     hierarchy; for example at the Autonomous System (AS) level.   At the 
  11894.     same time, policies can be specified  with sufficient detail in RPSL so
  11895.     that low level router configurations can be generated from them.  RPSL 
  11896.     is extensible; new routing protocols and new protocol features can be 
  11897.     introduced at any time.                                                
  11898.  
  11899.   "Application of Routing Policy Specification Language (RPSL) on the 
  11900.   Internet", David Meyer, Cengiz Alaettinoglu, J. Schmitz, 03/26/1997, 
  11901.   <draft-ietf-rps-appl-rpsl-00.txt, .ps>                                   
  11902.  
  11903.     This document is a tutorial on using the Routing Policy Specification 
  11904.     Language (RPSL) to specify routing policies.  It covers registering 
  11905.     policies in an Internet Routing Registry (IRR) using RPSL, and the use 
  11906.     of tools to generate vendor specific router configuration.  It is 
  11907.     targeted towards an Internet/Network Service Provider (ISP/NSP) 
  11908.     engineer who is new to RPSL and to IRR.  Readers are referred to the 
  11909.     RPSL reference document [1] for completeness.   We recommend reading 
  11910.     this document before reading the reference document. We hope that for 
  11911.     many cases, this document will be sufficient.                          
  11912.  
  11913.   "A strategy for the transition from RIPE-181 to RPSL", David Kessens, 
  11914.   08/02/1997, <draft-ietf-rps-transition-01.txt>                           
  11915.  
  11916.     This document describes a transition strategy for the Internet routing 
  11917.     registries from the RIPE181 [1] routing language to RPSL [2].          
  11918.  
  11919. Resource Reservation Setup Protocol (rsvp)
  11920. ------------------------------------------
  11921.  
  11922.   "RSVP Cryptographic Authentication", Fred Baker, 08/26/1997, 
  11923.   <draft-ietf-rsvp-md5-05.txt>                                             
  11924.  
  11925.     This document describes the format and use of RSVP's INTEGRITY
  11926.               object to provide hop-by-hop integrity and authentication of
  11927.               RSVP messages.                                               
  11928.  
  11929.   "RSVP Extensions for Policy Control", Shai Herzog, 03/20/1997, 
  11930.   <draft-ietf-rsvp-policy-ext-02.txt, .ps>                                 
  11931.  
  11932.     This memo describes a set of extensions for supporting generic policy 
  11933.     based admission control in RSVP. [Note 1]                              
  11934.     These extensions include the standard format of POLICY_DATA objects, a 
  11935.     generic RSVP/Policy-Control interface, and a description of RSVP's 
  11936.     handling of policy events.                                             
  11937.     This document does not advocate particular policy control mechanisms; 
  11938.     however, a Router/Server Policy Protocol description for these 
  11939.     extensions can be found in [LPM].                                      
  11940.  
  11941.   "RSVP Extensions for CIDR Aggregated Data Flows", J. Boyle, 06/26/1997, 
  11942.   <draft-ietf-rsvp-cidr-ext-01.txt>                                        
  11943.  
  11944.     This document presents extensions to Version 1 of the Resource 
  11945.     Reservation Setup Protocol (RSVP).  These extensions ameliorate RSVP 
  11946.     support of Large Scale Multicast Applications (LSMA) and Virtual 
  11947.     Private Networks (VPN).  With these types of applications, several 
  11948.     hosts at any particular site are participating in a session. Efficient 
  11949.     RSVP use requires aggregation of their addresses into a single entry 
  11950.     for classification purposes.  The extensions allow such aggregation of 
  11951.     state in a simple manner that requires no changes to the base RSVP 
  11952.     specification.                                                         
  11953.  
  11954.   "Designing Tunnels for Interoperability with RSVP", John Krawczyk, 
  11955.   03/12/1997, <draft-ietf-rsvp-tunnels-interop-00.txt>                     
  11956.  
  11957.     This memo provides information for designers of tunneling protocols 
  11958.     that use IP-in-IP encapsulation.  It describes how to design a tunnel 
  11959.     header so that RSVP [RSVPv1] can be used to signal the Quality of 
  11960.     Service requirements for individual flows within an IP-in-IP tunnel.   
  11961.  
  11962.   "Open Outsourcing Policy Service (OOPS) for RSVP", R. Guerin, Shai 
  11963.   Herzog, R. Rajan, D. Pendarakis, 08/05/1997, 
  11964.   <draft-ietf-rsvp-policy-oops-01.txt,.ps>                                 
  11965.  
  11966.     This document describes a protocol for exchanging policy information
  11967.     and decisions between an RSVP-capable router (client) and a policy
  11968.     server. The OOPS protocol supports a wide range of router
  11969.     configurations and RSVP implementations, and is compatible with the
  11970.     RSVP Extensions for Policy Control [Ext].                              
  11971.  
  11972.   "Partial Service Deployment in the Integrated Services Architecture", L. 
  11973.   Breslau, S. Shenker, 04/25/1997, <draft-ietf-rsvp-partial-service-00.txt>
  11974.  
  11975.     Specifications for providing enhanced qualities of service in the 
  11976.     Internet have been defined in [2,4].  Technical and administrative 
  11977.     concerns may prevent a network element from offering one or more of 
  11978.     these services.  In this document, we present a mechanism for dealing 
  11979.     with heterogeneity in the set of services offered by different network 
  11980.     elements.  This approach enables end-to-end service to be composed of 
  11981.     different per-hop services while not requiring end systems to be aware 
  11982.     of the details of the service provided at each hop.                    
  11983.  
  11984.   "RAPI -- An RSVP Application Programming Interface", Bob Braden, D. 
  11985.   Hoffman, 06/16/1997, <draft-ietf-rsvp-rapi-00.txt, .ps>                  
  11986.  
  11987.     This memo describes version 5 of RAPI, a specific API (application 
  11988.     programming interface) for RSVP.  The RAPI interface is one realization
  11989.     of the generic API contained in the RSVP Functional Specification 
  11990.     document, and it is being published for information only.  The RAPI 
  11991.     interface is based upon a client library, whose calls are described 
  11992.     here.                                                                  
  11993.  
  11994.   "Protocol for Exchange of PoliCy Information (PEPCI)", R. Yavatkar, Laura
  11995.   Cunningham, Ron Cohen, J. Boyle, David Durham, 07/28/1997, 
  11996.   <draft-ietf-rsvp-pepci-00.txt>                                           
  11997.  
  11998.     This document describes a simple client/server model for supporting 
  11999.     policy for RSVP, and is designed to be extensible so that other kinds 
  12000.     of client types may be supported in the future. The model does not make
  12001.     any assumptions about the algorithm of the policy server, but is based 
  12002.     on the server returning a single priority value in response to a policy
  12003.     request.  The objective is to use this very basic model to begin policy
  12004.     experimentation.                                                       
  12005.  
  12006.   "RSVP Management Information Base",, 10/13/1997, 
  12007.   <draft-ietf-rsvp-v2-mib-00.txt>                                          
  12008.  
  12009.     This memo defines a portion of the Management Information Base
  12010.     (MIB) for use with network management protocols in TCP/IP-
  12011.     based internets.  In particular, it defines objects for
  12012.     managing the Resource Reservation Protocol (RSVP) within the
  12013.     interface attributes defined in the Integrated Services Model.
  12014.     Thus, the Integrated Services MIB is directly relevant to and
  12015.     cross-referenced by this MIB.  Comments should be made to the
  12016.     RSVP Working Group, rsvp@isi.edu.
  12017.      
  12018.     This memo does not, in its draft form, specify a standard for
  12019.     the Internet community.                                                
  12020.  
  12021. Realtime Traffic Flow Measurement (rtfm)
  12022. ----------------------------------------
  12023.  
  12024.   "RTFM Working Group - New Attributes for Traffic Flow Measurement", 
  12025.   Gregory Ruth, Nevil Brownlee, Sig Handelman, 07/22/1997, 
  12026.   <draft-ietf-rtfm-new-traffic-flow-02.txt>                                
  12027.  
  12028.     The Real-time Traffic Flow Measurement (RTFM) Working Group has 
  12029.     developed a system for measuring and reporting information about 
  12030.     traffic flows in the Internet.  This document explores the definition 
  12031.     of extensions to the flow measurements as currently defined in [1] and 
  12032.     [5].  The new attributes described in this document will be useful for 
  12033.     monitoring network performance and expand the scope of RTFM beyond 
  12034.     simple measurement of traffic rates. Performance attributes typically 
  12035.     deal with throughput, packet loss, and delays. We will explore the 
  12036.     methods by which RTFM can extract values from flows so as to measure 
  12037.     these attributes. We will also look at capturing information on jitter 
  12038.     and congestion control.            The RTFM Working Group has defined 
  12039.     the concept of a standardized meter which records flows from a traffic 
  12040.     stream according to Rule Sets which are active in the meter[1].  
  12041.     Implementations of this meter have been done by Nevil Brownlee in the 
  12042.     University of Auckland, NZ, and Stephen Stibler and Sig Handelman at 
  12043.     IBM in Hawthorne, NY, USA. The RTFM WG has also defined the Meter 
  12044.     Reader Program whose job is to fetch flow data from the Meter.         
  12045.  
  12046.   "Traffic Flow Measurement:  Meter MIB", Nevil Brownlee, 09/24/1997, 
  12047.   <draft-ietf-rtfm-meter-mib-02.txt>                                       
  12048.  
  12049.     A 'Traffic Meter' collects data relating to traffic flows within a
  12050.     network.  This document defines a Management Information Base (MIB) for
  12051.     use in controlling a traffic meter, in particular for specifying the
  12052.     flows to be measured.  It also provides an efficient mechanism for
  12053.     retrieving flow data from the meter using SNMP. Security issues
  12054.     concerning the operation of traffic meters are summarised.
  12055.                                                                            
  12056.  
  12057.   "Traffic Flow Measurement:  Architecture",, 09/24/1997, 
  12058.   <draft-ietf-rtfm-architecture-00.txt>                                    
  12059.  
  12060.     This document describes an architecture for the measurement and
  12061.     reporting of network traffic flows, discusses how this relates to an
  12062.     overall network traffic flow architecture, and describes how it can be
  12063.     used within the Internet.  It is intended to provide a starting point
  12064.     for the Realtime Traffic Flow Measurement Working Group.               
  12065.  
  12066. Responsible Use of the Network (run)
  12067. ------------------------------------
  12068.  
  12069.   "DON'T SPEW     A Set of Guidelines for Mass Unsolicited Mailings and 
  12070.   Postings (Spam*)", Sally Hambridge, A. Lunde, 07/15/1997, 
  12071.   <draft-ietf-run-spew-01.txt>                                             
  12072.  
  12073.     This document provides explains why mass unsolicited electronic mail 
  12074.     messages are not useful in the Internetworking community.  It gives a 
  12075.     set of guidelines for dealing with unsolicited mail for users, for 
  12076.     system administrators, news administrators, and mailing list managers. 
  12077.     It also makes suggestions Internet Service Providers might follow.     
  12078.  
  12079. Secure Shell (secsh)
  12080. --------------------
  12081.  
  12082.   "SSH Transport Layer Protocol", T. Ylonen, 10/14/1997, 
  12083.   <draft-ietf-secsh-transport-02.txt>                                      
  12084.  
  12085.     SSH is a protocol for secure remote login and other secure network ser-
  12086.     vices over an insecure network.
  12087.      
  12088.     This document describes the SSH transport layer protocol which 
  12089.     typically
  12090.     runs on top of TCP/IP. The protocol can be used as a basis for a number
  12091.     of secure network services. It provides strong encryption, server
  12092.     authentication, and integrity protection. It may also provide
  12093.     compression.
  12094.      
  12095.     Key exchange method, public key algorithm, symmetric encryption
  12096.     algorithm, message authentication algorithm, and hash algorithm are all
  12097.     negotiated.
  12098.      
  12099.     This document also describes the Diffie-Hellman key exchange method and
  12100.     the minimal set of algorithms that are needed to implement the SSH
  12101.     transport layer protocol.                                              
  12102.  
  12103.   "SSH Authentication Protocol", T. Ylonen, Tero Kivinen, Markku Juhani 
  12104.   Saarinen, 10/14/1997, <draft-ietf-secsh-userauth-02.txt>                 
  12105.  
  12106.     SSH is a protocol for secure remote login and other secure network ser-
  12107.     vices over an insecure network.
  12108.      
  12109.     This document describes the SSH authentication protocol framework and
  12110.     public key, password, and host-based client authentication methods.
  12111.     Additional authentication methods are deferred to separate documents.
  12112.      
  12113.     The SSH authentication protocol runs on top the SSH transport layer
  12114.     protocol and provides a single authenticated tunnel for the SSH
  12115.     connection protocol.                                                   
  12116.  
  12117.   "SSH Connection Protocol", T. Ylonen, Tero Kivinen, Markku Juhani 
  12118.   Saarinen, 10/14/1997, <draft-ietf-secsh-connect-02.txt>                  
  12119.  
  12120.     SSH is a protocol for secure remote login and other secure network ser-
  12121.     vices over an insecure network.
  12122.      
  12123.     This document describes the SSH connection protocol. It provides
  12124.     interactive login sessions, remote execution of commands, forwarded
  12125.     TCP/IP connections, and forwarded X11 connections. All of these
  12126.     channels are multiplexed into a single encrypted tunnel.
  12127.      
  12128.     The SSH Connection Protocol has been designed to run on top of the
  12129.     SSH transport layer and user authentication protocols.                 
  12130.  
  12131.   "SSH Protocol Architecture", T. Ylonen, Tero Kivinen, Markku Juhani 
  12132.   Saarinen, 10/14/1997, <draft-ietf-secsh-architecture-00.txt>             
  12133.  
  12134.     SSH is a protocol for secure remote login and other secure network ser-
  12135.     vices over an insecure network.
  12136.      
  12137.     This document describes the architecture of the SSH protocol, and the
  12138.     notation and terminology used in SSH protocol documents. It also
  12139.     discusses the SSH algorithm naming system that allows local extensions.
  12140.      
  12141.     The SSH protocol consists of three major components: Transport layer
  12142.     protocol provides server authentication, confidentiality, and integrity
  12143.     with perfect forward secrecy. User authentication protocol 
  12144.     authenticates
  12145.     the client to the server. Connection protocol multiplexes the encrypted
  12146.     tunnel into several logical channels. Details of these protocols are
  12147.     described in separate documents.
  12148.                                                                            
  12149.  
  12150. SNA NAU Services MIB (snanau)
  12151. -----------------------------
  12152.  
  12153.   "Definitions of Managed Objects for DLUR", Robert Moore, B. Clouston, 
  12154.   05/12/1997, <draft-ietf-snanau-dlurmib-02.txt>                           
  12155.  
  12156.     This memo defines a portion of the Management Information Base (MIB) 
  12157.     for use with network management protocols in the Internet community.  
  12158.     In particular, it defines objects for monitoring and controlling 
  12159.     network devices with DLUR (Dependent LU Requester) capabilities.  This 
  12160.     memo identifies managed objects for the DLUR protocol.                 
  12161.     This memo does not specify a standard for the Internet community.      
  12162.  
  12163.   "Definitions of Managed Objects for HPR", Robert Moore, B. Clouston, 
  12164.   05/14/1997, <draft-ietf-snanau-hprmib-02.txt>                            
  12165.  
  12166.     This memo defines a portion of the Management Information Base (MIB) 
  12167.     for use with network management protocols in the Internet community.  
  12168.     In particular, it defines objects for monitoring and controlling 
  12169.     network devices with HPR (High Performance Routing) capabilities.  This
  12170.     memo identifies managed objects for the HPR protocol.                  
  12171.     This memo does not specify a standard for the Internet community.      
  12172.  
  12173.   "Definitions of Managed Objects for Extended Border Node", R. Moore, B. 
  12174.   Clouston, K. Lee, 09/02/1997, <draft-ietf-snanau-ebnmib-00.txt>          
  12175.  
  12176.     This memo defines a portion of the Management Information Base (MIB) 
  12177.     for
  12178.     use with network management protocols in the Internet community.  In
  12179.     particular, it defines objects for monitoring and controlling network
  12180.     devices with APPN (Advanced Peer-to-Peer Network) EBN (Extended Border
  12181.     Node) capabilities.  This memo identifies managed objects for the EBN
  12182.     architecture.
  12183.      
  12184.      
  12185.     This memo does not specify a standard for the Internet community.      
  12186.  
  12187. SNMP Version 3 (snmpv3)
  12188. -----------------------
  12189.  
  12190.   "An Architecture for Describing SNMP Management Frameworks", Bert Wijnen,
  12191.   Randy Presuhn, D. Harrington, 10/29/1997, 
  12192.   <draft-ietf-snmpv3-next-gen-arch-06.txt>                                 
  12193.  
  12194.     This document describes an architecture for describing SNMP
  12195.        Management Frameworks.  The architecture is designed to be modular 
  12196.     to   allow the evolution of the SNMP protocol standards over time.  The
  12197.        major portions of the architecture are an SNMP engine containing a
  12198.        Message Processing Subsystem, a Security Subsystem and an Access
  12199.        Control Subsystem, and possibly multiple SNMP applications which
  12200.        provide specific functional processing of management data.          
  12201.  
  12202.   "Local Processing Model for version 3 of the Simple Network Management 
  12203.   Protocol (SNMPv3)", Keith McCloghrie, Bert Wijnen, Randy Presuhn, 
  12204.   05/12/1997, <draft-ietf-snmpv3-lpm-01.txt>                               
  12205.  
  12206.     This document describes the Local Processing Model (LPM) for SNMP 
  12207.     version 3 for use in the SNMPng architecture [SNMPng-ARCH].  This 
  12208.     document defines the Elements of Procedure for accessing local 
  12209.     management information.  This document also includes a MIB for remotely
  12210.     monitoring/managing the configuration parameters for this LPM.         
  12211.  
  12212.   "Message Processing and Dispatching for the Simple Network Management 
  12213.   Protocol (SNMP)", Jeffrey Case, Bert Wijnen, Randy Presuhn, D. 
  12214.   Harrington, 10/30/1997, <draft-ietf-snmpv3-v3mpc-model-06.txt>           
  12215.  
  12216.        This document describes the Message Processing and Dispatching for
  12217.        SNMP messages within the SNMP architecture [SNMP-ARCH].  It defines
  12218.        the procedures for dispatching potentially multiple versions of SNMP
  12219.        messages to the proper SNMP Message Processing Models, and for
  12220.        dispatching PDUs to SNMP applications.  This document also describes
  12221.        one Message Processing Model - the SNMPv3 Message Processing Model. 
  12222.  
  12223.   "User-based Security Model for version 3 of the Simple Network Management
  12224.   Protocol (SNMPv3)", Bert Wijnen, U. Blumenthal, 06/18/1997, 
  12225.   <draft-ietf-snmpv3-usec-01.txt>                                          
  12226.  
  12227.     This document describes the User-based Security Model (USEC) for SNMP 
  12228.     version 3 for use in the SNMPng architecture [SNMPng-ARCH].  This 
  12229.     document defines the Elements of Procedure for providing SNMP message 
  12230.     level security.  This document also includes a MIB for remotely 
  12231.     monitoring/managing the configuration parameters for this Security 
  12232.     model.                                                                 
  12233.  
  12234.   "View-based Access Control Model (VACM) for the Simple Network Management
  12235.   Protocol (SNMP)", Keith McCloghrie, Bert Wijnen, Randy Presuhn, 
  12236.   10/29/1997, <draft-ietf-snmpv3-acm-04.txt>                               
  12237.  
  12238.     This document describes the View-based Access Control Model for use
  12239.     in the SNMP architecture [SNMP-ARCH].  It defines the Elements of
  12240.     Procedure for controlling access to management information.  This
  12241.     document also includes a MIB for remotely managing the configuration
  12242.     parameters for the View-based Access Control Model.                    
  12243.  
  12244.   "User-based Security Model (USM) for version 3 of the Simple Network 
  12245.   Management Protocol (SNMPv3)", Bert Wijnen, U. Blumenthal, 10/29/1997, 
  12246.   <draft-ietf-snmpv3-usm-03.txt>                                           
  12247.  
  12248.     This document describes the User-based Security Model (USM) for SNMP
  12249.     version 3 for use in the SNMP architecture [SNMP-ARCH].  It defines
  12250.     the Elements of Procedure for providing SNMP message level security.
  12251.     This document also includes a MIB for remotely monitoring/managing
  12252.     the configuration parameters for this Security Model.                  
  12253.  
  12254.   "SNMPv3 Applications", Bob Stewart, D. Levi, P. Meyer, 10/30/1997, 
  12255.   <draft-ietf-snmpv3-appl-04.txt>                                          
  12256.  
  12257.        This memo describes five types of SNMP applications which make use 
  12258.     of
  12259.        an SNMP engine as described in [SNMP-ARCH].  The types of 
  12260.     application
  12261.        described are Command Generators, Command Responders, Notification
  12262.        Originators, Notification Receivers, and Proxy Forwarders.
  12263.     
  12264.        This memo also defines MIB modules for specifying targets of
  12265.        management operations, for notification filtering, and for proxy
  12266.        forwarding.                                                         
  12267.  
  12268. Simple Public Key Infrastructure (spki)
  12269. ---------------------------------------
  12270.  
  12271.   "Simple Public Key Certificate", Butler Lampson, T. Ylonen, R. Rivest, W.
  12272.   Frantz, C. Ellison, B. Thomas, 07/31/1997, 
  12273.   <draft-ietf-spki-cert-structure-02.txt>                                  
  12274.  
  12275.     With the proliferation of public key cryptography on the Internet,
  12276.     there arises a need for certification of keys.  In the literature,
  12277.     the word 'certificate' has generally been taken to mean 'identity
  12278.     certificate': a signed statement which binds a key to the name of an
  12279.     individual and has the intended meaning of delegating authority from
  12280.     that named individual to the public key. (See, for example, RFC
  12281.     1422.)  This process is designed to copy a relationship between two
  12282.     entities from the physical world into the digital world.
  12283.      
  12284.     The Internet itself changed the world from the one in which identity
  12285.     certificates made sense.  We now deal with people we have never met
  12286.     and never will, which makes their names meaningless to us, but we
  12287.     still need to verify whether they are authorized to perform some
  12288.     action, achieve some access, sign some document, etc.
  12289.      
  12290.     SPKI certificates were designed to perform that function by directly
  12291.     specifying the (permission,key) binding which is of interest in the
  12292.     digital world.  As merged with SDSI, the current certificate format
  12293.     also allows someone to bind a key to a name in their own private name
  12294.     space.  The certificate structure presented here allows permissions
  12295.     to be delegated to SDSI-named individuals or to raw keys.              
  12296.  
  12297.   "SPKI Requirements", C. Ellison, 03/19/1997, 
  12298.   <draft-ietf-spki-cert-req-00.txt>                                        
  12299.  
  12300.     The IETF Simple Public Key Infrastructure [SPKI] Working Group is 
  12301.     tasked with producing a certificate structure and operating procedure 
  12302.     to meet the needs of the Internet community for trust management in as 
  12303.     easy, simple and extensible a way as possible.                         
  12304.     The SPKI WG first established a list of things one might want to do 
  12305.     with certificates (attached at the end of this document), and then 
  12306.     summarized that list of desires into requirements.  This document 
  12307.     presents that summary of requirements.                                 
  12308.  
  12309. Site Security Handbook (ssh)
  12310. ----------------------------
  12311.  
  12312.   "Users' Security Handbook", G. Malkin, Erik Guttman, 10/02/1997, 
  12313.   <draft-ietf-ssh-users-03.txt>                                            
  12314.  
  12315.        The Users' Security Handbook is the companion to the Site Security
  12316.        Handbook (SSH).  It is intended to provide users with the 
  12317.     information
  12318.        they need to keep their networks and systems secure.                
  12319.  
  12320. Guide for Internet Standards Writers (stdguide)
  12321. -----------------------------------------------
  12322.  
  12323.   "Guide for Internet Standards Writers", Art Mellor, Peter Desnoyers, Greg
  12324.   Scott, 05/28/1997, <draft-ietf-stdguide-ops-04.txt>                      
  12325.  
  12326.     This document is a guide for Internet standard writers.  It defines 
  12327.     those characteristics that make standards coherent, unambiguous, and 
  12328.     easy to interpret.  Also, it singles out usage believed to have led to 
  12329.     unclear specifications, resulting in non-interoperable interpretations 
  12330.     in the past.  These guidelines are to be used with RFC 1543, 
  12331.     'Instructions to RFC Authors.'                                         
  12332.     This version of the document is a draft.  It is intended to generate 
  12333.     further discussion and addition by the STDGUIDE working group.  Please 
  12334.     send comments to stdguide@midnight.com.                                
  12335.  
  12336. Service Location Protocol (svrloc)
  12337. ----------------------------------
  12338.  
  12339.   "Finding Stuff (How to discover services)", M. Hamilton, P. Leach, R. 
  12340.   Moats, 10/31/1997, <draft-ietf-svrloc-discovery-05.txt>                  
  12341.  
  12342.        This document proposes a solution to the problem of finding
  12343.        information about which services are being offered at a particular
  12344.        Internet domain.  Therefore, it is possible for clients, using this
  12345.        approach, to locate services in a domain with only prior knowledge 
  12346.     of
  12347.        the domain name.                                                    
  12348.  
  12349.   "Service Location Modifications for IPv6", John Veizades, Erik Guttman, 
  12350.   02/05/1997, <draft-ietf-svrloc-ipv6-01.txt>                              
  12351.  
  12352.     The Service Location Protocol provides a scalable framework for the 
  12353.     discovery and selection of network services.  Using this protocol, 
  12354.     computers using the Internet no longer need so much static 
  12355.     configuration of network services for network based applications.  This
  12356.     is especially important as computers become more portable, and users 
  12357.     less tolerant or able to fulfill the demands of network administration.
  12358.     The Service Location Protocol is well defined for use over IPv4 
  12359.     networks [SLP]:  This document defines its use over IPv6 networks.  
  12360.     Since this protocol relies on UDP and TCP, the changes to support its 
  12361.     use over IPv6 are minor.                                               
  12362.  
  12363.   "Service Templates and service:  Schemes", C. Perkins, Erik Guttman, 
  12364.   James Kempf, 10/15/1997, <draft-ietf-svrloc-service-scheme-03.txt>       
  12365.  
  12366.     The 'service:' URL scheme name is used to define URLs (called
  12367.        'service: URLs' in this document) that are primarily intended to be
  12368.        used by the Service Location Protocol in order to distribute service
  12369.        access information.  These schemes provide an extensible framework
  12370.        for client-based network software to obtain configuration 
  12371.     information
  12372.        required to make use of network services.  When registering a
  12373.        service: URL, the URL SHOULD be accompanied by a set of well-defined
  12374.        attributes which define the service.  These attributes SHOULD
  12375.        convey configuration information to client software, or service
  12376.        characteristics meaningful to end users.                            
  12377.  
  12378.   "An API for Service Location", D. Provan, Erik Guttman, 03/25/1997, 
  12379.   <draft-ietf-svrloc-api-01.txt>                                           
  12380.  
  12381.     The Service Location Protocol coupled with the Service Location API 
  12382.     provide a new way for clients to dynamically discovery network 
  12383.     services.  It is simple to offer highly available services which 
  12384.     require no user configuration or communication with network 
  12385.     administrators prior to use.  The document includes examples and 
  12386.     applications.                           Client software modified to use
  12387.     Service Location can make very simple requests to find service by type 
  12388.     or by characteristic. The latter capability allows the client to choose
  12389.     intelligently between services of the same type.  Service software 
  12390.     modified to use Service Location may dynamically advertise its 
  12391.     characteristics and existence.                                         
  12392.  
  12393.   "Advertising Services  (Providing information to support service 
  12394.   discovery)", M. Hamilton, R. Moats, 10/15/1997, 
  12395.   <draft-ietf-svrloc-advertising-03.txt>                                   
  12396.  
  12397.        This document proposes a solution to the problem of finding
  12398.        information about that services are being offered at a particular
  12399.        Internet domain, based on deployment experience with the Netfind
  12400.        White Pages directory software.
  12401.      
  12402.        This approach makes it possible to supply clients with more
  12403.        information than the DNS aliases that have been widely deployed in
  12404.        this role - notably the port numbers being used by servers.  
  12405.     However,
  12406.        it is not without problems, and we have tried to take account of
  12407.        these.
  12408.                                                                            
  12409.  
  12410.   "The 'wp:' and 'yp:' Abstract Service Types", R. Moats, 10/14/1997, 
  12411.   <draft-ietf-svrloc-wpyp-01.txt>                                          
  12412.  
  12413.        This document presents definitions for the 'wp:' (white pages) and
  12414.        'yp:' (yellow pages) abstract services.                             
  12415.  
  12416.   "Wide Area Network Service Location", J. Rosenberg, H. Schulzrinne, 
  12417.   07/25/1997, <draft-ietf-svrloc-wasrv-00.txt>                             
  12418.  
  12419.     This document discusses the problem of service location in wide area 
  12420.     networks. This problem arises when a user wishes to locate some 
  12421.     service, such as a media bridge, internet telephony gateway, H.323 
  12422.     Gate-keeper, unicast to multicast bridge, etc, which has some desired 
  12423.     characteristics, but whose location (in terms of IP address, domain, or
  12424.     geographical location) is completely unknown, and may be anywhere on 
  12425.     the public Internet. We focus on the problem of locating Internet 
  12426.     Telephony Gateways (devices which connect an IP host to a POTS user).  
  12427.     This particular location problem is characteristic of the general 
  12428.     problem; furthermore, location of these devices is particularly 
  12429.     difficult. Generally, the service location mechanisms need to be 
  12430.     invoked for every call setup. This implies that the call setup delays 
  12431.     will include the time to locate the gateway, and these delays should 
  12432.     therefore be kept to a minimum. With large numbers of gateways, the 
  12433.     location mechanisms can potentially become a network, processing, and 
  12434.     storage intensive operation. A solution to the gateway location problem
  12435.     must therefore be efficient and scalable in use of bandwidth, CPU 
  12436.     power, and disk storage.                                               
  12437.  
  12438.   "Conversion of LDAP Schemas to and from SLP Templates", Pete St. Pierre, 
  12439.   08/01/1997, <draft-ietf-svrloc-template-conversion-00.txt>               
  12440.  
  12441.     LDAP and SLP are both useful mechanisms for locating service related
  12442.        information on a network.  While they do perform similar functions,
  12443.        the way in which the information they provide is formated is very
  12444.        different.  This document describes a set of rules and mappings for
  12445.        translating between the ASN.1 based LDAP schema and an SLP Template
  12446.        as described in the ``Service Template and service:  Scheme''
  12447.        draft.[1]                                                           
  12448.  
  12449.   "Definition of lpr:  URLs for use with Service Location", Pete St. 
  12450.   Pierre, 07/31/1997, <draft-ietf-svrloc-lpr-scheme-00.txt>                
  12451.  
  12452.        This document defined the service:lpr scheme and attributes
  12453.        associated with it.  This template is designed to be used in
  12454.        conjuction with the Service Location Protocol [1], but may be
  12455.        used with any directory service supporting attribute/value pair
  12456.        registration.
  12457.                                                                            
  12458.  
  12459. TCP Implementation (tcpimpl)
  12460. ----------------------------
  12461.  
  12462.   "Known TCP Implementation Problems", Scott Dawson, Vern Paxson, 
  12463.   07/30/1997, <draft-ietf-tcpimpl-prob-01.txt>                             
  12464.  
  12465.     This memo catalogs a number of known TCP implementation problems.  The 
  12466.     goal in doing so is to improve conditions in the existing Internet by 
  12467.     enhancing the quality of current TCP/IP implementations.               
  12468.  
  12469.   "Some Testing Tools for TCP Implementors", S. Parker, C. Schmechel, 
  12470.   07/16/1997, <draft-ietf-tcpimpl-tools-00.txt>                            
  12471.  
  12472.     Available tools for testing TCP implementations are catalogued by this 
  12473.     memo.  Hopefully disseminating this information will encourage those 
  12474.     responsible for building and maintaing TCP to make the best use of 
  12475.     available tests.  The type of testing the tool provides, the type of 
  12476.     tests it is capable of doing, and its availability is enumerated.      
  12477.  
  12478. TCP Large Windows (tcplw)
  12479. -------------------------
  12480.  
  12481.   "TCP Extensions for High Performance", David Borman, V. Jacobson, Bob 
  12482.   Braden, 02/25/1997, <draft-ietf-tcplw-high-performance-00.txt>           
  12483.  
  12484.     This memo presents a set of TCP extensions to improve performance over 
  12485.     large bandwidth*delay product paths and to provide reliable operation 
  12486.     over very high-speed paths.  It defines new TCP options for scaled 
  12487.     windows and timestamps, which are designed to provide compatible 
  12488.     interworking with TCP's that do not implement the extensions.  The 
  12489.     timestamps are used for two distinct mechanisms:  RTTM (Round Trip Time
  12490.     Measurement) and PAWS (Protect Against Wrapped Sequences).  Selective 
  12491.     acknowledgments are not included in this memo.                         
  12492.     This memo updates and obsoletes RFC-1323, a Proposed Standard, with 
  12493.     small clarifications and corrections.                                  
  12494.  
  12495. TCP Over Satellite (tcpsat)
  12496. ---------------------------
  12497.  
  12498.   "Enhancing TCP Over Satellite Channels using Standard Mechanisms", Dan 
  12499.   Glover, M. Allman, 10/02/1997, <draft-ietf-tcpsat-stand-mech-00.txt>     
  12500.  
  12501.         The Transmission Control Protocol (TCP) provides reliable delivery
  12502.         of data across any network path, including network paths containing
  12503.         satellite channels.  While TCP works over satellite channels there
  12504.         are several mechanisms that enable TCP to more effectively utilize
  12505.         the available capacity of the network path.  This draft outlines
  12506.         some of these TCP mitigations.  At this time, all mitigations
  12507.         discussed in this draft are IETF standards track mechanisms.       
  12508.  
  12509. Transaction Internet Protocol (tip)
  12510. -----------------------------------
  12511.  
  12512.   "Transaction Internet Protocol    Version 2.0", Jim Lyon, J. Klein, Keith
  12513.   Evans, 10/21/1997, <draft-lyon-itp-nodes-03.txt>                         
  12514.  
  12515.        In many applications where different nodes cooperate on some work,
  12516.        there is a need to guarantee that the work happens atomically. That
  12517.        is, each node must reach the same conclusion as to whether the work
  12518.        is to be completed, even in the face of failures.  This document
  12519.        proposes a simple, easily-implemented protocol for achieving this
  12520.        end.                                                                
  12521.  
  12522.   "Session Control Protocol V 2.0", S. Spero, Jim Lyon, J. Klein, Keith 
  12523.   Evans, 05/01/1997, <draft-evans-v2-scp-00.txt>                           
  12524.  
  12525.     This document describes version 2.0 of the Session Control Protocol 
  12526.     (SCP)[1]. SCP provides a simple mechanism for creating multiple 
  12527.     lightweight connections over a single TCP connection. Several such 
  12528.     lightweight connections can be active simultaneously. SCP provides a 
  12529.     byte oriented service, but allows message boundaries to be marked.     
  12530.  
  12531. Transport Layer Security (tls)
  12532. ------------------------------
  12533.  
  12534.   "Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)", 
  12535.   M. Hur, A. Medvinsky, 07/25/1997, 
  12536.   <draft-ietf-tls-kerb-cipher-suites-01.txt>                               
  12537.  
  12538.     This document proposes the addition of new cipher suites to the TLS 
  12539.     protocol [1] to support Kerberos-based authentication.  Kerberos 
  12540.     credentials are used to achieve mutual authentication and to establish 
  12541.     a master secret which is subsequently used to secure client-server 
  12542.     communication.                                                         
  12543.  
  12544.   "The TLS Protocol  Version 1.0", C. Allen, T. Dierks, 10/29/1997, 
  12545.   <draft-ietf-tls-protocol-04.txt>                                         
  12546.  
  12547.        This document specifies Version 1.0 of the Transport Layer Security
  12548.        (TLS) protocol. The TLS protocol provides communications privacy
  12549.        over the Internet. The protocol allows client/server applications to
  12550.        communicate in a way that is designed to prevent eavesdropping,
  12551.        tampering, or message forgery.                                      
  12552.  
  12553. Telnet TN3270 Enhancements (tn3270e)
  12554. ------------------------------------
  12555.  
  12556.   "TN3270 Enhancements", B. Kelly, 05/28/1997, 
  12557.   <draft-ietf-tn3270e-ver2-enhance-00.txt>                                 
  12558.  
  12559.     This document describes a protocol that more fully supports 3270 
  12560.     devices than do the existing tn3270 practices.  Specifically, it 
  12561.     defines a method of emulating both the terminal and printer members of 
  12562.     the 3270 family of devices via Telnet; it provides for the ability of a
  12563.     Telnet client to request that it be assigned a specific device-name 
  12564.     (also referred to as 'LU name' or 'network name'); finally, it adds 
  12565.     support for a variety of functions such as the ATTN key, the SYSREQ 
  12566.     key, and SNA response handling. This protocol is negotiated under the 
  12567.     TN3270E Telnet Option, and is unrelated to the Telnet 3270 Regime 
  12568.     Option as defined in RFC 1041[1].                                      
  12569.  
  12570.   "Base Definitions of Managed Objects for TN3270E Using SMIv2", K. White, 
  12571.   09/15/1997, <draft-ietf-tn3270e-tn3270-mib-03.txt>                       
  12572.  
  12573.     The purpose of this memo is to define a Management Information Base
  12574.       (MIB) for configuring and managing TN3270E Servers.
  12575.       The MIB defined by this memo is intended to provide generic
  12576.       support for both Host and Gateway TN3270E server implementations.
  12577.       It is the intent that the MIB defined herein be extended
  12578.       by subsequent memos to provide non-generic configuration support
  12579.       and to enable TN3270E Response Time Collection.
  12580.      
  12581.       It is the intent of this MIB to fully adhere to all prerequisite MIBs
  12582.       unless explicitly stated. Deviations will be documented in
  12583.       corresponding conformance statements. The specification of this MIB
  12584.       will utilize the Structure of Management Information (SMI) for
  12585.       Version 2 of the Simple Network Management Protocol Version (refer to
  12586.       RFC1902, reference [1]).                                             
  12587.  
  12588.   "Definitions of Managed Objects for TN3270E Response Time Collection 
  12589.   Using SMIv2", Robert Moore, K. White, 10/08/1997, 
  12590.   <draft-ietf-tn3270e-rt-mib-01.txt>                                       
  12591.  
  12592.     The purpose of this memo is to define the protocol and the Management
  12593.     Information Base (MIB) for performing response time data collection
  12594.     on TN3270 and TN3270E sessions by a TN3270E Server. The response time 
  12595.     data collected by a TN3270E Server is structured to support both 
  12596.     validation of service level agreements and performance monitoring of
  12597.     TN3270 and TN3270E Sessions. This MIB has as a prerequisite the 
  12598.     TN3270E-MIB reference [10].                                            
  12599.  
  12600. DS1/DS3 MIB (trunkmib)
  12601. ----------------------
  12602.  
  12603.   "Definitions of Managed Objects for the DS1, E1, DS2 and E2 Interface 
  12604.   Types", D. Fowler, 06/02/1997, <draft-ietf-trunkmib-ds1-mib-06.txt>      
  12605.  
  12606.     This memo defines an experimental portion of the Management Information
  12607.     Base (MIB) for use with network management protocols in the Internet 
  12608.     community.  In particular, it describes objects used for managing DS1, 
  12609.     E1, DS2 and E2 interfaces.  This document is a companion document with 
  12610.     Definitions of Managed Objects for the DS0, DS3/E3 and SONET/SDH 
  12611.     Interface Types, rfcTBD [19], rfcTBD [17] and rfcTBD [18].             
  12612.     This memo specifies a MIB module in a manner that is both compliant to 
  12613.     the SNMPv2 SMI, and semantically identical to the peer SNMPv1 
  12614.     definitions.     This memo does not specify a standard for the Internet
  12615.     community.          This document entirely replaces RFC 1406.          
  12616.  
  12617.   "Definitions of Managed Objects for the DS3/E3 Interface Type", Tracy 
  12618.   Brown, Kaj Tesink, D. Fowler, 06/02/1997, 
  12619.   <draft-ietf-trunkmib-ds3-mib-05.txt>                                     
  12620.  
  12621.     This memo defines an experimental portion of the Management Information
  12622.     Base (MIB) for use with network management protocols in the Internet 
  12623.     community.  In particular, it describes objects used for managing DS3 
  12624.     and E3 interfaces.  This document is a companion document with 
  12625.     Definitions of Managed Objects for the DS0, DS1/E1/DS2/E2 and SONET/SDH
  12626.     Interface Types, rfcTBD [14], rfcTBD [6] and rfcTBD [7].               
  12627.     This memo specifies a MIB module in a manner that is both compliant to 
  12628.     the SNMPv2 SMI, and semantically identical to the peer SNMPv1 
  12629.     definitions. This memo does not specify a standard for the Internet 
  12630.     community.        This document entirely replaces RFC 1407.            
  12631.  
  12632.   "Definitions of Managed Objects for the DS0 and DS0 Bundle Interface 
  12633.   Type", D. Fowler, 06/02/1997, <draft-ietf-trunkmib-ds0-mib-04.txt>       
  12634.  
  12635.     This memo defines an experimental portion of the Management Information
  12636.     Base (MIB) for use with network management protocols in the Internet 
  12637.     community.  In particular, it describes objects used for managing DS0 
  12638.     and DS0 Bundle interfaces.  This document is a companion document with 
  12639.     Definitions of Managed Objects for the DS1/E1/DS2/E2, DS3/E3 and 
  12640.     SONET/SDH Interface Types, rfcTBD [6], rfcTBD [7] and rfc1595 [8].     
  12641.     This memo specifies a MIB module in a manner that is both compliant to 
  12642.     the SNMPv2 SMI, and semantically identical to the peer SNMPv1 
  12643.     definitions.     This memo does not specify a standard for the Internet
  12644.     community.                                                             
  12645.  
  12646. Uniform Resource Identifiers (uri)
  12647. ----------------------------------
  12648.  
  12649.   "The Handle System", D. Ely, W. Arms, 05/05/1997, 
  12650.   <draft-ietf-uri-urn-handles-00.txt>                                      
  12651.  
  12652.     The Handle System provides identifiers for digital objects and other 
  12653.     resources in distributed computer systems.  These identifiers are known
  12654.     as handles.  The system ensures that handles are unique and that they 
  12655.     can be retained over long time periods.   Since the system makes no 
  12656.     assumptions about the characteristics of the items that are identified,
  12657.     handles can be used in a wide variety of systems and applications.     
  12658.     The handle system has the following components:  naming authorities, 
  12659.     handle generators, the global handle server, local handle servers, 
  12660.     caching handle servers, client software libraries, proxy servers, and 
  12661.     administrative tools.  For reasons of performance and availability, the
  12662.     global, local, and caching servers are implemented as distributed 
  12663.     systems comprising many server computers.  All components, except the 
  12664.     local handle server, have been implemented and are available for 
  12665.     general use by the research community.     The handle system provides 
  12666.     all the capabilities listed in RFC1737, K. Sollins, L. Masinter, 
  12667.     'Functional Requirements for Uniform Resource Names', 12/20/1994.      
  12668.  
  12669. Uniform Resource Locator Registration Procedures (urlreg)
  12670. ---------------------------------------------------------
  12671.  
  12672.   "Guidelines for new URL Schemes", Harald Alvestrand, Larry Masinter, D. 
  12673.   Zigmond, 10/27/1997, <draft-ietf-urlreg-guide-00.txt>                    
  12674.  
  12675.     A Uniform Resource Locator (URL) is a compact string representation
  12676.        of the location for a resource that is available via the Internet.
  12677.        [RFC URL-SYNTAX] defines the general syntax and semantics of URLs.
  12678.        This document provides guidelines for the definition of new URL
  12679.        schemes and describes the process by which they are registered.     
  12680.  
  12681. Uniform Resource Names (urn)
  12682. ----------------------------
  12683.  
  12684.   "Architectural Principles of Uniform Resource Name Resolution", K. 
  12685.   Sollins, 09/26/1997, <draft-ietf-urn-req-frame-04.txt>                   
  12686.  
  12687.     This document addresses the issues of the discovery of URN (Uniform
  12688.     Resource Name) resolver services that in turn will directly translate
  12689.     URNs into URLs (Uniform Resource Locators) and URCs (Uniform Resource
  12690.     Characteristics).  The document falls into three major parts, the
  12691.     assumptions underlying the work, the guidelines in order to be a
  12692.     viable Resolver Discovery Service or RDS, and a framework for
  12693.     designing RDSs.  The guidelines fall into three principle areas:
  12694.     evolvability, usability, and security and privacy.  An RDS that is
  12695.     compliant with the framework will not necessarily be compliant with
  12696.     the guidelines.  Compliance with the guidelines will need to be
  12697.     validated separately.                                                  
  12698.  
  12699.   "Namespace Identifier Requirements for URN Services", Patrik Faltstrom, 
  12700.   R. Iannella, 03/27/1997, <draft-ietf-urn-nid-req-01.txt>                 
  12701.  
  12702.     Services that offer to resolve Uniform Resource Names implicitly 
  12703.     require that they support a persistent and reliable service for an 
  12704.     indeterminate length of time. This draft outlines the requirements for 
  12705.     any such service that wishes to participate as a Namespace Identifier. 
  12706.  
  12707.   "URI Resolution Services Necessary for URN Resolution", M. Mealling, R. 
  12708.   Daniel, 08/09/1997, <draft-ietf-urn-resolution-services-03.txt>          
  12709.  
  12710.     Retrieving the resource identified by a Uniform Resource Identifier 
  12711.     (URI) [3] is only one of the operations that can be performed on a URI.
  12712.     One might also ask for and get a list of other identifiers that are 
  12713.     aliases for the original URI or a bibliographic description of the 
  12714.     resource the URI denotes, for example. This applies to both Uniform 
  12715.     Resource Names (URNs) and Uniform Resource Locators (URLs). Uniform 
  12716.     Resource Characteristics (URCs) are discussed in this document but only
  12717.     as descriptions of resources rather than identifiers.
  12718.      
  12719.     A service in the network providing access to a resource may provide one
  12720.     or some of these options, but it need not provide all of them. This 
  12721.     memo
  12722.     specifies an initial set of these functions, to be used to describe the
  12723.     functions provided by any given access service and the requirements 
  12724.     that
  12725.     must be met when those operations are encoded in a protocol.
  12726.                                                                            
  12727.  
  12728.   "Using Existing Bibliographic Identifiers as Uniform Resource Names", C. 
  12729.   Lynch, C. Preston, R. Daniel, 09/26/1997, <draft-ietf-urn-biblio-02.txt> 
  12730.  
  12731.     A system for Uniform Resource Names (URNs) must be capable
  12732.     of supporting identifiers from existing widely-used naming
  12733.     systems.  This document discusses how three major
  12734.     bibliographic identifiers (the ISBN, ISSN and SICI) can be
  12735.     supported within the URN framework and the currently
  12736.     proposed syntax for URNs.                                              
  12737.  
  12738.   "URN Syntax", R. Moats, 05/05/1997, <draft-ietf-urn-syntax-05.txt>       
  12739.  
  12740.     Uniform Resource Names (URNs) are intended to serve as persistent, 
  12741.     location-independent, resource identifiers. This document sets forward 
  12742.     the canonical syntax for URNs.  A discussion of both existing legacy 
  12743.     and new namespaces and requirements for URN presentation and 
  12744.     transmission are presented.  Finally, there is a discussion of URN 
  12745.     equivalence and how to determine it.                                   
  12746.  
  12747.   "A URN Namespace for IETF Documents", R. Moats, 07/14/1997, 
  12748.   <draft-ietf-urn-ietf-02.txt>                                             
  12749.  
  12750.     A system for Uniform Resource Names (URNs) must be capable of 
  12751.     supporting new naming systems.  As an example of how a new namespace 
  12752.     may be proposed, this document presents a naming system based on the 
  12753.     RFC family of documents (RFCs, STDs, and FYIs) developed by the IETF 
  12754.     and published by the RFC editor and the minutes of working groups (WG) 
  12755.     and birds of a feather (BOF) meetings that occur during IETF 
  12756.     conferences.  This namespace can be supported within the URN framework 
  12757.     and the currently proposed syntax for URNs.                            
  12758.  
  12759. 100VG-AnyLAN MIB (vgmib)
  12760. ------------------------
  12761.  
  12762.   "Definitions of Managed Objects for IEEE 802.12 Repeater Devices", J. 
  12763.   Flick, 05/20/1997, <draft-ietf-vgmib-repeater-dev-04.txt>                
  12764.  
  12765.     This memo defines a portion of the Management Information Base (MIB) 
  12766.     for use with network management protocols in TCP/IP-based internets. In
  12767.     particular, it defines objects for managing network repeaters based on 
  12768.     IEEE 802.12.                                                           
  12769.  
  12770. Virtual Router Redundancy Protocol (vrrp)
  12771. -----------------------------------------
  12772.  
  12773.   "Virtual Router Redundancy Protocol", Peter Higginson, Bob Hinden, S. 
  12774.   Knight, Danny Mitzel, M. Shand, D. Whipple, D. Weaver, Peter Hunt, 
  12775.   10/27/1997, <draft-ietf-vrrp-spec-03.txt>                                
  12776.  
  12777.     This memo defines the Virtual Router Redundancy Protocol (VRRP).
  12778.        VRRP specifies an election protocol that dynamically allows a set of
  12779.        routers running VRRP to backup each other on a LAN.  The VRRP router
  12780.        controlling one or more IP addresses is called the Master router, 
  12781.     and
  12782.        forwards packets sent to these IP addresses.  The election process  
  12783.     provides dynamic fail over in the forwarding responsibility should
  12784.        the Master become unavailable.  This allows any of the VRRP routers
  12785.        IP addresses on the LAN to be used as the default first hop router 
  12786.     by
  12787.        end-hosts.  The advantage gained from using the VRRP is a higher
  12788.        availability default path without requiring configuration of dynamic
  12789.        routing or router discovery protocols on every end-host.            
  12790.  
  12791. WWW Distributed Authoring and Versioning (webdav)
  12792. -------------------------------------------------
  12793.  
  12794.   "HTTP-based Distributed Content Editing Scenarios", O. Lassila, 
  12795.   06/03/1997, <draft-ietf-webdav-scenarios-00.txt>                         
  12796.  
  12797.     This document contains examples of distributed editing conducted 
  12798.     through HTTP. These scenarios have been developed by the Distributed 
  12799.     Authoring and Versioning Group in the course of specifying requirements
  12800.     for distributed editing, and aim to demonstrate the concepts of 
  12801.     distributed editing.  The document presents a logical hierarchy of 
  12802.     scenarios, separating actual editing actions from document management. 
  12803.  
  12804.   "Requirements for a Distributed Authoring and Versioning Protocol for the
  12805.   World Wide Web", D. Durand, Jim Whitehead, J. Slein, F. Vitali, 
  12806.   09/23/1997, <draft-ietf-webdav-requirements-03.txt>                      
  12807.  
  12808.     Current World Wide Web (WWW or Web) standards provide simple support
  12809.     for applications which allow remote editing of typed data. In practice,
  12810.     the existing capabilities of the WWW have proven inadequate to support
  12811.     efficient, scalable remote editing free of overwriting conflicts.
  12812.     This document presents a list of features in the form of requirements
  12813.     for a Web Distributed Authoring and Versioning protocol which, if
  12814.     implemented, would improve the efficiency of common remote editing
  12815.     operations, provide a locking mechanism to prevent overwrite conflicts,
  12816.     improve link management support between non-HTML data types, provide
  12817.     a simple attribute-value metadata facility, provide for the creation
  12818.     and reading of container data types, and integrate versioning into
  12819.     the WWW.                                                               
  12820.  
  12821.   "Extensions for Distributed Authoring and Versioning on the World Wide 
  12822.   Web -- WEBDAV", Jim Whitehead, D. Jensen, S. Carter, Y. Goland, A. Faizi,
  12823.   10/15/1997, <draft-ietf-webdav-protocol-04.txt>                          
  12824.  
  12825.               This Document specifies a set of methods and content-types
  12826.               ancillary to HTTP/1.1 for the management of resource 
  12827.     properties,
  12828.               simple name space manipulation, simple resource locking
  12829.               (collision avoidance) and resource version control.          
  12830.  
  12831.   "WebDAV Tree Operations", Y. Goland, 10/09/1997, 
  12832.   <draft-ietf-webdav-depth-00.txt>                                         
  12833.  
  12834.        The WebDAV protocol specification [Goland et al., 1997] defines the
  12835.        DELETE, COPY and MOVE methods. However these methods have a scope of
  12836.        a single source resource. It is common for principals to wish to
  12837.        perform a DELETE, COPY or MOVE on a collection and all its internal
  12838.        members. This specification defines the DELETE-TREE, COPY-TREE and
  12839.        MOVE-TREE methods that perform the equivalent of DELETE, COPY and
  12840.        MOVE across a collection and all its progeny.                       
  12841.  
  12842. Web Transaction Security (wts)
  12843. ------------------------------
  12844.  
  12845.   "The Secure HyperText Transfer Protocol", A. Schiffman, E. Rescorla, 
  12846.   03/25/1997, <draft-ietf-wts-shttp-04.txt>                                
  12847.  
  12848.     This memo describes a syntax for securing messages sent using the 
  12849.     Hypertext Transfer Protocol (HTTP), which forms the basis for the World
  12850.     Wide Web. Secure HTTP (S-HTTP) provides independently applicable 
  12851.     security services for transaction confidentiality, 
  12852.     authenticity/integrity and non-repudiability of origin.                
  12853.     The protocol emphasizes maximum flexibility in choice of key management
  12854.     mechanisms, security policies and cryptographic algorithms by 
  12855.     supporting option negotiation between parties for each transaction.    
  12856.  
  12857.   "Security Extensions For HTML", A. Schiffman, E. Rescorla, 03/25/1997, 
  12858.   <draft-ietf-wts-shtml-03.txt>                                            
  12859.  
  12860.     This memo describes a syntax for embedding S-HTTP negotiation 
  12861.     parameters in HTML documents. S-HTTP as described by 
  12862.     draft-ietf-wts-shttp-03.txt contains the concept of negotation headers 
  12863.     which reflect the potential receiver of a message's preferences as to 
  12864.     which cryptographic enhancements should be applied to the message. This
  12865.     document describes a syntax for binding these negotiation parameters to
  12866.     HTML anchors.                                                          
  12867.  
  12868.  
  12869.  
  12870.  
  12871.