Internet DRAFT - draft-andreasen-mmusic-sdpcapneg-att-del

draft-andreasen-mmusic-sdpcapneg-att-del









     MMUSIC Working Group                                       F. Andreasen 
     Internet-Draft                                            Cisco Systems 
     Intended Status: None                                      June 7, 2007 
     Expires: December 2007                                                  
                                         
                                           
                             SDP Capability Negotiation:  
                          Deleting and Replacing Attributes 
                   draft-andreasen-mmusic-sdpcapneg-att-del-00.txt 


     Status of this Memo 

        By submitting this Internet-Draft, each author represents that       
        any applicable patent or other IPR claims of which he or she is       
        aware have been or will be disclosed, and any of which he or she       
        becomes aware will be disclosed, in accordance with Section 6 of       
        BCP 79. 

        Internet-Drafts are working documents of the Internet Engineering 
        Task Force (IETF), its areas, and its working groups.  Note that 
        other groups may also distribute working documents as Internet-
        Drafts. 

        Internet-Drafts are draft documents valid for a maximum of six months 
        and may be updated, replaced, or obsoleted by other documents at any 
        time.  It is inappropriate to use Internet-Drafts as reference 
        material or to cite them other than as "work in progress." 

        The list of current Internet-Drafts can be accessed at 
             http://www.ietf.org/ietf/1id-abstracts.txt 

        The list of Internet-Draft Shadow Directories can be accessed at 
             http://www.ietf.org/shadow.html 

        This Internet-Draft will expire on December 7, 2007. 

     Copyright Notice 

        Copyright (C) The IETF Trust (2007). 

     Abstract 

        The current SDP Capability Negotiation solution includes the ability 
        for a potential configuration to delete and replace individual 
        attributes from the actual configuration. This capability introduces 
        some complexity into the SDP Capability Negotiation framework and 
        this document examines the need for having this feature and proposes 
        a way forward.  

      
      
      
     Andreasen              Expires December 7, 2007                [Page 1] 
      







     Internet-Draft        SDP Capability Negotiation              June 2007 
         

         

     Table of Contents 

         
        1. Introduction...................................................2 
        2. Conventions used in this document..............................2 
        3. To Add, Delete or Replace Attributes...........................2 
           3.1. Deleting Attributes.......................................3 
              3.1.1. 1) Unintended processing of a well-known attribute when 
              parts of the SDP is changed.................................4 
              3.1.2. Unclear interactions between two different attributes 
              (for example two different attribute names).................6 
           3.2. Replace Attributes........................................7 
        4. Conclusion.....................................................8 
        5. Security Considerations........................................9 
        6. IANA Considerations............................................9 
        7. References....................................................10 
           7.1. Normative References.....................................10 
           7.2. Informative References...................................10 
        Author's Addresses...............................................12 
        Intellectual Property Statement..................................13 
        Full Copyright Statement.........................................13 
        Acknowledgment...................................................13 
         
     1. Introduction 

        The current SDP Capability Negotiation solution [sdpcapneg] includes 
        the ability for a potential configuration to delete and replace 
        individual attributes from the actual configuration. This capability 
        introduces some complexity into the SDP Capability Negotiation 
        framework. In this document, we examine the need for having this 
        feature in Section 3. and then propose a way forward in Section 4.  

        It is assumed that the reader is familiar with the [sdpcapneg]. 

     2. Conventions used in this document 

        The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
        "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
        document are to be interpreted as described in [RFC2119]. 

     3. To Add, Delete or Replace Attributes 

        In the SDP Capability Negotiation framework solution [sdpcapneg] the 
        SDP provided includes attributes as part of the actual configuration 
        in the offer (and answer) SDP. If one or more attributes are unknown 
      
      
     Andreasen              Expires December 7, 2007                [Page 2] 
         







     Internet-Draft        SDP Capability Negotiation              June 2007 
         

        or unsupported, the answerer will ignore those attributes per normal 
        SDP rules [RFC4566].  

        The SDP Capability Negotiation framework defines attribute 
        capabilities, and enables one or more of those attribute capabilities 
        to be used in one of the potential configuration SDPs, whereby it 
        becomes part of the alternative offer. The potential configuration 
        SDP is formed by taking the actual configuration SDP (the offer) and 
        add the attribute capability values that are referenced by the 
        potential configuration.  

        The primary reason for doing this is to control which attribute 
        capability values are part of a potential configuration SDP. This 
        enables alternative attribute types and values to be ordered by 
        preference and for different attributes (including different types, 
        e.g. keying mechanisms) to be chosen for a particular potential 
        configuration. 

        The SDP Capability Negotiation framework currently also defines 
        mechanisms for: 

        1) DELETING one or more attributes from the actual configuration SDP 
        when forming the potential configuration SDP  

        2) REPLACING one or more attributes from the actual configuration SDP 
        with an attribute capability value when forming the potential 
        configuration SDP.  

        The ability to delete and replace attributes from the actual 
        configuration SDP adds some complexity to the SDP Capability 
        Negotiation framework. The question has been raised whether these 
        features are necessary. Below we provide motivation for each.  

     3.1. Deleting Attributes 

        When it comes to the need for deleting attributes from the actual 
        configuration SDP, the basic question is whether presence of a 
        particular SDP attribute can cause unintended operation to occur, 
        i.e., can an SDP attribute actually be harmful. Since SDP will always 
        ignore unknown attributes, harmful operation can occur only when a 
        particular attribute is supported by the recipient (answerer).  

        At the heart of this issue is how SDP attributes are processed, and 
        in particular whether presence of what appears to be a meaningless 
        SDP attribute can interfere with normal or intended offer/answer 
        processing. For example, if a UDP-based media stream is being 
        established, and TCP-based parameters are included (e.g. per RFC 
      
      
     Andreasen              Expires December 7, 2007                [Page 3] 
         







     Internet-Draft        SDP Capability Negotiation              June 2007 
         

        4145), will those parameters be ignored, or will the answerer instead 
        view the SDP (or media stream) as malformed and reject it ?  

         

        Since SDP requires unknown attributes to be ignored, and general IETF 
        principles prescribe being liberal in what you receive, we will 
        *assume*, that in the absence of specific rules to the contrary, an 
        SDP implementation will indeed ignore not only unknown SDP 
        attributes, but also SDP attributes that do not otherwise seem to 
        apply to a given SDP. Without this assumption, the issue at hand is 
        closed inasmuch as we clearly would need the ability to delete 
        attributes.  

        With the above assumption, we are left with two classes of problems 
        for specific well-known attributes: 

        1) Unintended processing of a well-known attribute when parts of the 
        SDP is changed.  

        2) Unclear interactions between two different attributes (for example 
        two different attribute names).  

        Below, we look at each of these separately and provide example 
        scenarios 

     3.1.1. 1) Unintended processing of a well-known attribute when parts of 
        the SDP is changed. 

        An example of this is when the actual configuration offers an SRTP 
        media stream, and the alternative potential configuration uses plain 
        RTP. In the following example, the actual configuration includes 
        keying material in a "crypto" attribute as illustrated below: 

        v=0  
        o=alice 2891092738 2891092738 IN IP4 lost.example.com  
        s=   
        t=0 0  
        c=IN IP4 lost.example.com  
        m=audio 59000 RTP/SAVP 0 
        a=crypto:1 AES_CM_128_HMAC_SHA1_32     
                 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32   
        a=tcap RTP/SAVP RTP/AVP 
        a=acap:1 a=crypto:1 AES_CM_128_HMAC_SHA1_32     
                 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32  
        a=pcfg:1 a=1 t=1  

      
      
     Andreasen              Expires December 7, 2007                [Page 4] 
         







     Internet-Draft        SDP Capability Negotiation              June 2007 
         

         

        The resulting potential configuration SDP for the plain RTP 
        alternative (the actual configuration, which by default is the least 
        preferred alternative) would look like this, if we don't delete the 
        actual configuration attributes: 

        v=0  
        o=alice 2891092738 2891092738 IN IP4 lost.example.com  
        s=   
        t=0 0  
        c=IN IP4 lost.example.com  
        m=audio 59000 RTP/AVP 0 
        a=crypto:1 AES_CM_128_HMAC_SHA1_32     
                 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32   

        Note that we have a "crypto" attribute with a plain RTP media stream.  

        When processing this potential configuration, it would be best to 
        delete the "crypto" attribute from the configuration. Otherwise, the 
        media stream could get rejected. From RFC 4568, Section 5.1.2: 

        <quote> 
        When the answerer receives the initial offer with one or more crypto 
        attributes for a given unicast media stream, the answerer MUST either 
        accept exactly one of the offered crypto attributes, or the offered 
        stream MUST be rejected. 
        </quote> 

        Section 5 in RFC 4568 is transport protocol agnostic, with Section 7 
        providing the SRTP specific behavior. Section 7.1.2 says: 

        <quote> 
        When the initial answer is generated, the answerer MUST follow the 
        steps in Section 5.1.2, as well as the following steps. 
        For each unicast media line that uses the secure RTP transport and 
        contains one or more "a=crypto" lines in the offer, the answerer MUST 
        either accept one (and only one) of the crypto lines for that media 
        stream, or it MUST reject the media stream. 
        </quote> 

        and later on 

        <quote> 
        If the answerer cannot find any valid crypto line that it supports, 
        or if its configured policy prohibits any cryptographic key parameter  
        e.g., key length) or cryptographic session parameter (e.g., KDR, 
      
      
     Andreasen              Expires December 7, 2007                [Page 5] 
         







     Internet-Draft        SDP Capability Negotiation              June 2007 
         

        FEC_ORDER), it MUST reject the media stream, unless it is able to 
        successfully negotiate use of SRTP by other means outside the scope 
        of this document (e.g., by use of MIKEY [mikey]). 
        </quote> 

        It is somewhat open to interpretation whether Section 7.1.2 implies 
        that the crypto operation will only happen if we actually have an 
        SRTP stream in the "m=" line. However, if we want to be on the safe 
        side, we should not provide any crypto attribute with a vanilla RTP 
        stream, and that is part of the reason for having the "delete" 
        semantics in the SDP Capability Negotiation. 

     3.1.2. Unclear interactions between two different attributes (for 
        example two different attribute names). 

        An example of this is the "keymgt" and "crypto" attributes used for 
        SRTP keying. Assume the actual configuration offers an SRTP media 
        stream using the "crypto" attribute as the keying mechanism, whereas 
        an alternative potential configuration suggests use of MIKEY or DTLS-
        SRTP.  

        The actual configuration SDP could look like this: 

        v=0  
        o=alice 2891092738 2891092738 IN IP4 lost.example.com  
        s=   
        t=0 0  
        c=IN IP4 lost.example.com  
        m=audio 59000 RTP/SAVP 0 
        a=crypto:1 AES_CM_128_HMAC_SHA1_32     
                 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32   
        a=tcap:1 RTP/SAVP UDP/TLS/RTP/AVP 
        a=acap:1 a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO...     
        a=acap:2 a=setup:actpass 
        a=acap:3 a=connection:new 
        a=acap:4 a=fingerprint:SHA-1 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:... 
        a=pcfg:1 t=1 a=1  
        a=pcfg:2 t=2 a=2,3,4 

         

        The resulting potential configuration SDP for SRTP using MIKEY would 
        look like this: 

        v=0 
        o=alice 2891092738 2891092738 IN IP4 lost.example.com  
        s=   
      
      
     Andreasen              Expires December 7, 2007                [Page 6] 
         







     Internet-Draft        SDP Capability Negotiation              June 2007 
         

        t=0 0  
        c=IN IP4 lost.example.com  
        m=audio 59000 RTP/SAVP 0 
        a=crypto:1 AES_CM_128_HMAC_SHA1_32     
                 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32   
        a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO...     

        There are two issues with this potential configuration SDP. First of 
        all, it contains both a crypto and a key-mgmt attribute, however only 
        one of these should be used for negotiating SRTP security parameters. 
        Fortunately, RFC 4568 (Section 7.5) specifically addresses this 
        interaction issue by mandating that only of them is actually 
        processed, however it nevertheless illustrates the interaction issue.  

        The resulting potential configuration SDP for DTLS-SRTP would look 
        like this: 

        v=0 
        o=alice 2891092738 2891092738 IN IP4 lost.example.com  
        s=   
        t=0 0  
        c=IN IP4 lost.example.com  
        m=audio 59000 UDP/TLS/RTP/AVP 0 
        a=crypto:1 AES_CM_128_HMAC_SHA1_32     
                 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32   
        a=setup:actpass 
        a=connection:new 
        a=fingerprint:SHA-1 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:... 

        This potential configuration SDP suffers from the same issue as the 
        plain RTP one in the previous scenario; presence of the crypto 
        attribute with a transport protocol for which it is not to be used.  

     3.2. Replace Attributes 

         Attribute replacement is similar deleting an attribute and then 
        adding another one, however the issues behind this feature differ 
        from that of simple deletion. The basic problems motivating this 
        feature are: 

         

        1) An attribute value may conflict with another attribute value.  

        Examples of this include "rtpmap" and "fmtp" parameters. If the SDP 
        contains an "rtpmap:96 PCMU" and the potential configuration adds 

      
      
     Andreasen              Expires December 7, 2007                [Page 7] 
         







     Internet-Draft        SDP Capability Negotiation              June 2007 
         

        "rtpmap:96 G729", then which mapping is actually the right one to use 
        ? To avoid this ambiguity, RFC 4566 states that  

        <quote> 
        Up to one rtpmap attribute can be defined for each media format 
        specified. 
        </quote> 

        The issue is similar for the "fmtp" parameter.  

        A possible alternative solution to replacing attributes would be to 
        define an order in which attributes are added to the potential 
        configuration SDP, and then define conflict resolution for well -
        known attribute types (such as fmtp and rtpmap), however the concern 
        with doing so is that it is not a general solution. We cannot specify 
        rules for attributes that are yet to be defined, and we miss some 
        attribute types. 

     4. Conclusion  

        We have presented the rationale behind 

        - deleting attributes in an actual configuration SDP 

        - replacing attributes in an actual configuration SDP 

        In terms of deleting attributes, we made an important assumption 
        about implementations generally ignoring SDP attributes that do not 
        seem to otherwise apply for a particular SDP. This left us with the 
        problem of dealing only with attributes that may result in unintended 
        processing when the SDP changes or attributes that have unclear 
        interactions. We have looked at a variety of different SDP attributes 
        for this class of problems, however our primary use cases seem to 
        center around SRTP key management. This suggests that the problem is 
        somewhat limited in scope when it comes to current SDP parameters.  

        In terms of replacing attributes, there are clear use cases for this, 
        notably in the areas of the "fmtp" and "rtpmap" attributes. Both of 
        these are outside the scope of the core SDP capability negotiation 
        document, however they are within scope of the media capabilities 
        negotiation work. 

        While there is little doubt (in the author's mind at least) that 
        there is an important general problem here, it could be argued that 
        it would be sufficient to provide a solution in the core document 
        that does not define how individual attributes are deleted from the 
        actual configuration. If that path is followed, it is the author's 
      
      
     Andreasen              Expires December 7, 2007                [Page 8] 
         







     Internet-Draft        SDP Capability Negotiation              June 2007 
         

        opinion that we should still provide the ability to delete all 
        attributes from the existing SDP (at the media and/or session-level) 
        thereby providing a simple (albeit somewhat inefficient in terms of 
        message size) solution to the general problem, that all 
        implementations are guaranteed to support. 

     5. Security Considerations 

        None.  

     6. IANA Considerations 

        None.   


































      
      
     Andreasen              Expires December 7, 2007                [Page 9] 
         







     Internet-Draft        SDP Capability Negotiation              June 2007 
         

     7. References 

     7.1. Normative References 

        [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 
                  Requirement Levels", BCP 14, RFC 2119, March 1997. 

        [RFC3264] Rosenberg, J., and H. Schulzrinne, "An Offer/Answer Model 
                  with Session Description Protocol (SDP)", RFC 3264, June 
                  2002.  

        [RFC3407] F. Andreasen, "Session Description Protocol (SDP) Simple 
                  Capability Declaration", RFC 3407, October 2002. 

        [RFC3605] C. Huitema, "Real Time Control Protocol (RTCP) attribute in 
                  Session Description Protocol (SDP)", RFC 3605, October 
                  2003.  

        [RFC4234] Crocker, D., and P. Overell, "Augmented BNF for Syntax 
                  Specifications: ABNF", RFC 4234, October 2005. 

        [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 
                  Description Protocol", RFC 4566, July 2006.  

        [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 
                  IANA Considerations Section in RFCs", BCP 26, RFC 2434, 
                  October 1998. 

     7.2. Informative References 

        [RFC2046] Freed, N., and N. Borensteain, "Multipurpose Internet Mail 
                  Extensions (MIME) Part Two: Media Types", RFC 2046, 
                  November 1996. 

        [RFC2327] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 
                  Description Protocol", RFC 2327, April 1998.  

        [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 
                  A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, 
                  "SIP: Session Initiation Protocol", RFC 3261, June 2002. 

        [RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H. 
                  Schulzrinne, "Grouping of Media Lines in the Session 
                  Description Protocol (SDP)", RFC 3388, December 2002. 



      
      
     Andreasen              Expires December 7, 2007               [Page 10] 
         







     Internet-Draft        SDP Capability Negotiation              June 2007 
         

        [RFC3551] Schulzrinne, H., and S. Casner, "RTP Profile for Audio and 
                  Video Conferences with Minimal Control", RFC 3551, July 
                  2003.  

        [SRTP]    Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 
                  Norrman, "The Secure Real-time Transport Protocol (SRTP)", 
                  RFC 3711, March 2004. 

        [RFC3851] B. Ramsdell, "Secure/Multipurpose Internet Mail Extensions 
                  (S/MIME) Version 3.1 Message Specification", RFC 3851, July 
                  2004.  

        [RFC4091] Camarillo, G., and J. Rosenberg, The Alternative Network 
                  Address Types (ANAT) Semantics for the Session Description 
                  Protocol (SDP) Grouping Framework, RFC 4091, June 2005.  

        [AVPF]    Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 
                  "Extended RTP Profile for RTCP-Based Feedback (RTP/AVPF)", 
                  Work in Progress, August 2004.  

        [I-D.jennings-sipping-multipart] Wing, D., and C. Jennings, "Session 
                  Initiation Protocol (SIP) Offer/Answer with Multipart 
                  Alternative", Work in Progress, March 2006. 

        [SAVPF]   Ott, J., and E Carrara, "Extended Secure RTP Profile for 
                  RTCP-based Feedback (RTP/SAVPF)", Work in Progress, 
                  December 2005.  

        [SDES]    Andreasen, F., Baugher, M., and D. Wing, "Session 
                  Description Protocol Security Descriptions for Media 
                  Streams", RFC 4568, July 2006.  

        [SDPng]   Kutscher, D., Ott, J., and C. Bormann, "Session Description 
                  and Capability Negotiation", Work in Progress, February 
                  2005.  

        [BESRTP]  Kaplan, H., and F. Audet, "Session Description Protocol 
                  (SDP) Offer/Answer Negotiation for Best-Effort Secure Real-
                  Time Transport Protocol, Work in progress, August 2006.  

        [KMGMT]   Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. 
                  Carrara, "Key Management Extensions for Session Description 
                  Protocol (SDP) and Real Time Streaming Protocol (RTSP)", 
                  RFC 4567, July 2006.  



      
      
     Andreasen              Expires December 7, 2007               [Page 11] 
         







     Internet-Draft        SDP Capability Negotiation              June 2007 
         

        [SDPCapNegRqts]   Andreasen, F. "SDP Capability Negotiation: 
                  Requirementes and Review of Existing Work", work in 
                  progress, December 2006. 

        [SDPCapNeg] Andreasen, F. "SDP Capability Negotiation", work in 
                  progress, March 2007. 

        [MIKEY]   J. Arkko, E. Carrara, F. Lindholm, M. Naslund, and K. 
                  Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 
                  August 2004.  

        [ICE]     J. Rosenberg, "Interactive Connectivity Establishment 
                  (ICE): A Methodology for Network Address Translator (NAT) 
                  Traversal for Offer/Answer Protocols", work in progress, 
                  January 2007. 

        [ICETCP]  J. Rosenberg, "TCP Candidates with Interactive Connectivity 
                  Establishment (ICE)", work in progress, October 2006. 

         

        [RFC3312] G. Camarillo, W. Marshall, and J. Rosenberg, "Integration 
                  of Resource Management and Session Initiatio Protocol 
                  (SIP)", RFC 3312, October 2002.  

        [SMIME]   B. Ramsdell, "Secure/Multipurpose Internet Mail Extensions 
                  (S/MIME) Version 3.1 Message Specification", RFC 3851, July 
                  2004. 

        [RFC4474] J. Peterson, and C. Jennings, "Enhancements for 
                  Authenticated Identity Management in the Session Initiation 
                  Protocol (SIP)", RFC 4474, August 2006.  

        [sprecon] Andreasen, F. and D. Wing, "Security Preconditions for 
                  Session Description Protocol Media Streams", Work in 
                  Progress, October 2006. 

         

     Author's Addresses 

        Flemming Andreasen 
        Cisco Systems 
        Edison, NJ 
            
        Email: fandreas@cisco.com 
         
      
      
     Andreasen              Expires December 7, 2007               [Page 12] 
         







     Internet-Draft        SDP Capability Negotiation              June 2007 
         

     Intellectual Property Statement 

        The IETF takes no position regarding the validity or scope of any 
        Intellectual Property Rights or other rights that might be claimed to 
        pertain to the implementation or use of the technology described in 
        this document or the extent to which any license under such rights 
        might or might not be available; nor does it represent that it has 
        made any independent effort to identify any such rights.  Information 
        on the procedures with respect to rights in RFC documents can be 
        found in BCP 78 and BCP 79. 

        Copies of IPR disclosures made to the IETF Secretariat and any 
        assurances of licenses to be made available, or the result of an 
        attempt made to obtain a general license or permission for the use of 
        such proprietary rights by implementers or users of this 
        specification can be obtained from the IETF on-line IPR repository at 
        http://www.ietf.org/ipr. 

        The IETF invites any interested party to bring to its attention any 
        copyrights, patents or patent applications, or other proprietary 
        rights that may cover technology that may be required to implement 
        this standard.  Please address the information to the IETF at 
        ietf-ipr@ietf.org. 

     Full Copyright Statement 

        Copyright (C) The IETF Trust (2007). 

        This document is subject to the rights, licenses and restrictions 
        contained in BCP 78, and except as set forth therein, the authors 
        retain all their rights. 

        This document and the information contained herein are provided on an 
        "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 
        OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 
        THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 
        OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 
        THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
        WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 

     Acknowledgment 

        Funding for the RFC Editor function is currently provided by the 
        Internet Society. 

         

      
      
     Andreasen              Expires December 7, 2007               [Page 13]