--- 1/draft-ietf-mpls-rsvp-lsp-fastreroute-05.txt	2006-02-05 00:42:35.000000000 +0100
+++ 2/draft-ietf-mpls-rsvp-lsp-fastreroute-06.txt	2006-02-05 00:42:35.000000000 +0100
@@ -1,17 +1,18 @@
+
 Internet Draft                               Ping Pan, Ed  (Ciena Corp)
 Expires: November 2004               George Swallow, Ed (Cisco Systems)
                                          Alia Atlas, Ed (Avici Systems)
 
            Fast Reroute Extensions to RSVP-TE for LSP Tunnels
 
-              draft-ietf-mpls-rsvp-lsp-fastreroute-05.txt
+              draft-ietf-mpls-rsvp-lsp-fastreroute-06.txt
 
 Status of this Memo
 
    This document is an Internet-Draft and is in full conformance with
    all provisions of Section 10 of RFC2026.
 
    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.
@@ -87,21 +88,21 @@
           8.1.2.1  An Example on Path Message Merging  ............ 31
         8.1.3  Message Handling for Merged Detours  ............... 32
       8.2  Handling Failures  ..................................... 32
     9  Behavior of all LSRs  ...................................... 33
       9.1  Merging Detours in Path-Specific Method  ............... 33
    10  Security Considerations  ................................... 34
    11  IANA Guidelines  ........................................... 34
    12  Intellectual Property Considerations  ...................... 34
    13  Full Copyright Statement  .................................. 35
    14  Acknowledgments  ........................................... 35
-   15  Normative References  ...................................... 35
+   15  Normative References  ...................................... 36
    16  Editor Information  ........................................ 36
 
 1.  Authors
 
    This document was written by George Swallow, Ping Pan, Alia Atlas,
    Jean Philippe Vasseur, Markus Jork, Der-Hwa Gan, and Dave Cooper.
 
    Jean Philippe Vasseur
    Cisco Systems, Inc.
    300 Beaver Brook Road
@@ -1538,30 +1539,40 @@
    This document does not introduce new security issues. The security
    considerations pertaining to the original RSVP protocol [RSVP] remain
    relevant.
 
    It should be noted that the facility backup technique requires that
    a PLR and its selected Merge Point will trust RSVP messages
    received from each other.
 
 11. IANA Section
 
-   IANA [RFC-IANA] will assign RSVP Class-Num 205 for the
-   FAST_REROUTE and RSVP Class-Num 63 for the DETOUR object.  This
+   IANA [RFC-IANA] will assign RSVP Class Number 205 for the
+   FAST_REROUTE and RSVP Class Number 63 for the DETOUR object.  This
    matches the current usage in production networks.
 
    IANA will assign C-Type 1 for the standard FAST_REROUTE object
    format defined in section 5.1 and list C-Type 7 as reserved as it
-   is still used by pre-standard implementations.
+   is still used by pre-standard implementations.  Future C-Types
+   will be assigned using the following guidelines:
 
-   IANA will assign C-Types 7 and 8 to the IPv4 and IPv6 DETOUR
-   object formats as defined in section 5.2.
+       C-Types 0 through 127 are assigned by Standards Action.
+       C-Types 128 through 191 are assigned by Expert Review.
+       C-Types 192 through 255 are reserved for Vendor Private Use.
+
+   IANA will assign C-Types 7 and 8 to the IPv4 and IPv6 DETOUR object
+   formats as defined in section 5.2.  Future C-Types will be
+   assigned using the following guidelines:
+
+       C-Types 0 through 127 are assigned by Standards Action.
+       C-Types 128 through 191 are assigned by Expert Review.
+       C-Types 192 through 255 are reserved for Vendor Private Use.
 
 12. Intellectual Property Considerations
 
    The IETF takes no position regarding the validity or scope of any
    intellectual property 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; neither does it represent that it
    has made any effort to identify any such rights.  Information on the
    IETF's procedures with respect to rights in standards-track and