draft-ietf-pce-path-key-05.txt   draft-ietf-pce-path-key-06.txt 
Networking Working Group Rich Bradford (Ed) Networking Working Group Rich Bradford (Ed)
Internet-Draft JP Vasseur Internet-Draft JP Vasseur
Intended Status: Standards Track Cisco Systems, Inc. Intended Status: Standards Track Cisco Systems, Inc.
Created: November 17, 2008 Adrian Farrel Created: March 7, 2009 Adrian Farrel
Expires: May 17, 2009 Old Dog Consulting Expires: September 7, 2009 Old Dog Consulting
Preserving Topology Confidentiality in Inter-Domain Path Preserving Topology Confidentiality in Inter-Domain Path
Computation Using a Key-Based Mechanism Computation Using a Key-Based Mechanism
draft-ietf-pce-path-key-05.txt draft-ietf-pce-path-key-06.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79. the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 3, line 41 skipping to change at page 3, line 41
another domain thus breaking the confidentiality requirement another domain thus breaking the confidentiality requirement
stated in [RFC4105] and [RFC4216]. We define the part of the path stated in [RFC4105] and [RFC4216]. We define the part of the path
which we wish to keep confidential as the Confidential Path which we wish to keep confidential as the Confidential Path
Segment (CPS). Segment (CPS).
One mechanism for preserving the confidentiality of the CPS is for One mechanism for preserving the confidentiality of the CPS is for
the PCE to return a path containing a loose hop in place of the the PCE to return a path containing a loose hop in place of the
segment that must be kept confidential. The concept of loose and segment that must be kept confidential. The concept of loose and
strict hops for the route of a TE LSP is described in [RFC3209]. strict hops for the route of a TE LSP is described in [RFC3209].
The Path Computation Element Communication Protocol (PCEP) defined The Path Computation Element Communication Protocol (PCEP) defined
in [PCEP] supports the use of paths with loose hops, and it is a in [RFC5440] supports the use of paths with loose hops, and it is a
local policy decision at a PCE whether it returns a full explicit local policy decision at a PCE whether it returns a full explicit
path with strict hops or uses loose hops. Note that a Path path with strict hops or uses loose hops. Note that a Path
computation Request may request an explicit path with strict hops computation Request may request an explicit path with strict hops
or may allow loose hops as detailed in [PCEP]. or may allow loose hops as detailed in [RFC5440].
The option of returning a loose hop in place of the CPS can be The option of returning a loose hop in place of the CPS can be
achieved without further extensions to PCEP or the signaling achieved without further extensions to PCEP or the signaling
protocol. If loose hops are used, the TE LSPs are signaled as protocol. If loose hops are used, the TE LSPs are signaled as
normal ([RFC3209]), and when a loose hop is encountered in the normal ([RFC3209]), and when a loose hop is encountered in the
explicit route it is resolved by performing a secondary path explicit route it is resolved by performing a secondary path
computation to reach the resource or set of resources identified computation to reach the resource or set of resources identified
by the loose hop. Given the nature of the cooperation between PCEs by the loose hop. Given the nature of the cooperation between PCEs
in computing the original path, this secondary computation occurs in computing the original path, this secondary computation occurs
at or on behalf of a Label Switching Router (LSR) at a domain at or on behalf of a Label Switching Router (LSR) at a domain
skipping to change at page 4, line 23 skipping to change at page 4, line 23
LSPs are signaled, and since the TE LSP signaling proceeds LSPs are signaled, and since the TE LSP signaling proceeds
independently for each TE LSP, disjoint paths cannot be guaranteed independently for each TE LSP, disjoint paths cannot be guaranteed
since the LSRs in charge of expanding the EROs are not synchronized. since the LSRs in charge of expanding the EROs are not synchronized.
Therefore, if the loose hop technique is used without further Therefore, if the loose hop technique is used without further
extensions, path segment confidentiality and path diversity are extensions, path segment confidentiality and path diversity are
mutually incompatible requirements. mutually incompatible requirements.
This document defines the notion of a Path Key that is a token This document defines the notion of a Path Key that is a token
that replaces a path segment in an explicit route. The Path Key is that replaces a path segment in an explicit route. The Path Key is
encoded as a Path Key Subobject (PKS) returned in the PCEP Path encoded as a Path Key Subobject (PKS) returned in the PCEP Path
Computation Reply message (PCRep) ([PCEP]). Upon receiving the Computation Reply message (PCRep) ([RFC5440]). Upon receiving the
computed path, the PKS will be carried in an RSVP-TE Path message computed path, the PKS will be carried in an RSVP-TE Path message
(RSVP-TE [RFC3209] and [RSVP-PKS]) during signaling. (RSVP-TE [RFC3209] and [RSVP-PKS]) during signaling.
The BNF in this document follows the format described in [RBNF]. The BNF in this document follows the format described in [RBNF].
1.1. Terminology 1.1. Terminology
This document makes use of the following terminology and acronyms. This document makes use of the following terminology and acronyms.
AS: Autonomous System. AS: Autonomous System.
skipping to change at page 6, line 21 skipping to change at page 6, line 21
will occur at the start of the CPS which will usually be the will occur at the start of the CPS which will usually be the
domain boundary. The PKS MUST be preceded by an ERO subobject that domain boundary. The PKS MUST be preceded by an ERO subobject that
identifies the LSR that must expand the PKS. This means that identifies the LSR that must expand the PKS. This means that
(following the rules for ERO processing set out in [RFC3209]) (following the rules for ERO processing set out in [RFC3209])
the PKS will not be encountered in ERO processing until the ERO is the PKS will not be encountered in ERO processing until the ERO is
being processed by the LSR that is capable of correctly handling the being processed by the LSR that is capable of correctly handling the
PKS. PKS.
An LSR that encounters a PKS when trying to identify the next-hop An LSR that encounters a PKS when trying to identify the next-hop
retrieves the PCE-ID from the PKS and sends a Path Computation retrieves the PCE-ID from the PKS and sends a Path Computation
Request (PCReq) message as defined in [PCEP] to the PCE identified Request (PCReq) message as defined in [RFC5440] to the PCE identified
by the PCE-ID that contains the path-key object . by the PCE-ID that contains the path-key object .
Upon receiving the PCReq message, the PCE identifies the computed Upon receiving the PCReq message, the PCE identifies the computed
path segment using the supplied path-key, and returns the path segment using the supplied path-key, and returns the
previously computed path segment in the form of explicit hops previously computed path segment in the form of explicit hops
using an ERO object contained in the Path Computation Reply using an ERO object contained in the Path Computation Reply
(PCReqp) to the requesting node as defined in [PCEP]. The (PCReqp) to the requesting node as defined in [RFC5440]. The
requesting node inserts the explicit hops into the ERO and requesting node inserts the explicit hops into the ERO and
continues to process the TE LSP setup as per [RFC3209]. continues to process the TE LSP setup as per [RFC3209].
2.2. Example 2.2. Example
Figure 1 shows a simple two-AS topology with a PCE responsible Figure 1 shows a simple two-AS topology with a PCE responsible
for the path computations in each AS. An LSP is requested from for the path computations in each AS. An LSP is requested from
the ingress LSR in one AS to the egress LSR in the other AS. The the ingress LSR in one AS to the egress LSR in the other AS. The
ingress, acting as PCC, sends a path computation request to PCE- ingress, acting as PCC, sends a path computation request to PCE-
1. PCE-1 is unable to compute an end-to-end path and invokes PCE- 1. PCE-1 is unable to compute an end-to-end path and invokes PCE-
skipping to change at page 9, line 53 skipping to change at page 9, line 53
address of the PCE that is always reachable, but MAY be an address of the PCE that is always reachable, but MAY be an
address that is restricted to the domain in which the LSR that address that is restricted to the domain in which the LSR that
is called upon to expand the CPS lies. Other values that have is called upon to expand the CPS lies. Other values that have
no meaning outside the domain (for example, the IPv6 TE Router no meaning outside the domain (for example, the IPv6 TE Router
ID) MAY be used to increase security (see Section 5). ID) MAY be used to increase security (see Section 5).
3.2. Unlocking Path Keys 3.2. Unlocking Path Keys
When a network node needs to decode a Path Key so that it can When a network node needs to decode a Path Key so that it can
continue signaling for an LSP, it must send a PCReq to the continue signaling for an LSP, it must send a PCReq to the
designated PCE. The PCReq defined in [PCEP] needs to be modified designated PCE. The PCReq defined in [RFC5440] needs to be modified
to support this usage which differs from the normal path to support this usage which differs from the normal path
computation request. To that end, a new flag is defined to show computation request. To that end, a new flag is defined to show
that the PCReq relates to the expansion of a PKS, and a new object that the PCReq relates to the expansion of a PKS, and a new object
is defined to carry the PKS in the PCReq. These result in an is defined to carry the PKS in the PCReq. These result in an
update to the BNF for the message. The BNF used in this document is update to the BNF for the message. The BNF used in this document is
as described in [RBNF]. as described in [RBNF].
3.2.1. Path Key Bit 3.2.1. Path Key Bit
[PCEP] defines the Request Parameters (RP) object that is used to [RFC5440] defines the Request Parameters (RP) object that is used to
specify various characteristics of the path computation request specify various characteristics of the path computation request
(PCReq). (PCReq).
In this document we define a new bit named the Path Key bit as In this document we define a new bit named the Path Key bit as
follows. See Section 7.3 for the IANA assignment of the follows. See Section 7.3 for the IANA assignment of the
appropriate bit number. appropriate bit number.
Path Key bit: When set, the requesting PCC requires the retrieval Path Key bit: When set, the requesting PCC requires the retrieval
of a Confidential Path Segment that corresponds to the PKS carried of a Confidential Path Segment that corresponds to the PKS carried
in a PATH_KEY object in the path computation request. The Path Key in a PATH_KEY object in the path computation request. The Path Key
skipping to change at page 11, line 48 skipping to change at page 11, line 48
If the receiving PCE does not recognize itself as identified by the If the receiving PCE does not recognize itself as identified by the
PCE ID carried in the PKS it MAY forward the PCReq message to PCE ID carried in the PKS it MAY forward the PCReq message to
another PCE according to local policy. If the PCE does not forward another PCE according to local policy. If the PCE does not forward
such a PCReq, it MUST respond with a PCRep message containing a NO- such a PCReq, it MUST respond with a PCRep message containing a NO-
PATH object. PATH object.
If the receiving PCE recognizes itself, but cannot find the If the receiving PCE recognizes itself, but cannot find the
related CPS, or if the retrieval of the CPS is not allowed by related CPS, or if the retrieval of the CPS is not allowed by
policy, the PCE MUST send a PCRep message that contains a NO-PATH policy, the PCE MUST send a PCRep message that contains a NO-PATH
object. The NO-PATH-VECTOR TLV SHOULD be used as described in object. The NO-PATH-VECTOR TLV SHOULD be used as described in
[PCEP] and a new bit-number (see Section 7.4) is assigned to [RFC5440] and a new bit-number (see Section 7.4) is assigned to
indicate "Cannot expand PKS". indicate "Cannot expand PKS".
Upon receipt of a negative reply, the requesting LSR MUST fail the Upon receipt of a negative reply, the requesting LSR MUST fail the
LSP setup and SHOULD use the procedures associated with loose hop LSP setup and SHOULD use the procedures associated with loose hop
expansion failure [RFC3209]. expansion failure [RFC3209].
5. Security Considerations 5. Security Considerations
This document describes tunneling confidential path information This document describes tunneling confidential path information
across an untrusted domain (such as an AS). There are many across an untrusted domain (such as an AS). There are many
skipping to change at page 12, line 23 skipping to change at page 12, line 23
- Confidentiality of the CPS (can other network elements probe for - Confidentiality of the CPS (can other network elements probe for
expansion of path-keys, possibly at random?). expansion of path-keys, possibly at random?).
- Authenticity of the path-key (resilience to alteration by - Authenticity of the path-key (resilience to alteration by
intermediaries, resilience to fake expansion of path-keys). intermediaries, resilience to fake expansion of path-keys).
- Resilience from DoS attacks (insertion of spurious path-keys; - Resilience from DoS attacks (insertion of spurious path-keys;
flooding of bogus path-key expansion requests). flooding of bogus path-key expansion requests).
Most of the interactions required by this extension are point to Most of the interactions required by this extension are point to
point, can be authenticated and made secure as described in [PCEP] point, can be authenticated and made secure as described in [RFC5440]
and [RFC3209]. These interactions include the: and [RFC3209]. These interactions include the:
- PCC->PCE request - PCC->PCE request
- PCE->PCE request(s) - PCE->PCE request(s)
- PCE->PCE response(s) - PCE->PCE response(s)
- PCE->PCC response - PCE->PCC response
- LSR->LSR request and response (Note that a rogue LSR could - LSR->LSR request and response (Note that a rogue LSR could
modify the ERO and insert or modify Path Keys. This would modify the ERO and insert or modify Path Keys. This would
result in an LSR (which is downstream in the ERO) sending result in an LSR (which is downstream in the ERO) sending
decode requests to a PCE. This is actually a larger problem decode requests to a PCE. This is actually a larger problem
skipping to change at page 15, line 48 skipping to change at page 15, line 48
signaling. signaling.
Since the PCE that inserted the PKS requires to keep the CPS Since the PCE that inserted the PKS requires to keep the CPS
confidential, the legacy head-end LSR cannot be protected. It must confidential, the legacy head-end LSR cannot be protected. It must
either fail the LSP setup, or request a new path computation either fail the LSP setup, or request a new path computation
avoiding the domain that has supplied it with unknown subobjects. avoiding the domain that has supplied it with unknown subobjects.
7. IANA Considerations 7. IANA Considerations
IANA assigns values to PCEP parameters in registries defined in IANA assigns values to PCEP parameters in registries defined in
[PCEP]. IANA is requested to make the following additional [RFC5440]. IANA is requested to make the following additional
assignments. assignments.
7.1. New Subobjects for the ERO Object 7.1. New Subobjects for the ERO Object
IANA has previously assigned an Object-Class and Object-Type to IANA has previously assigned an Object-Class and Object-Type to
the ERO carried in PCEP messages [PCEP]. IANA also maintains a the ERO carried in PCEP messages [RFC5440]. IANA also maintains a
list of subobject types valid for inclusion in the ERO. list of subobject types valid for inclusion in the ERO.
IANA is requested to assign two new subobject types for inclusion IANA is requested to assign two new subobject types for inclusion
in the ERO as follows: in the ERO as follows:
Subobject Type Subobject Type
64 Path Key with 32-bit PCE ID [This.I-D] 64 Path Key with 32-bit PCE ID [This.I-D]
65 Path Key with 128-bit PCE ID [This.I-D] 65 Path Key with 128-bit PCE ID [This.I-D]
7.2. New PCEP Object 7.2. New PCEP Object
skipping to change at page 16, line 33 skipping to change at page 16, line 33
Subobjects Subobjects
This object may carry the following subobjects as defined This object may carry the following subobjects as defined
for the ERO object. for the ERO object.
64 Path Key with 32-bit PCE ID [This.I-D] 64 Path Key with 32-bit PCE ID [This.I-D]
65 Path Key with 128-bit PCE ID [This.I-D] 65 Path Key with 128-bit PCE ID [This.I-D]
7.3. New RP Object Bit Flag 7.3. New RP Object Bit Flag
IANA maintains a registry of bit flags carried in the PCEP RP IANA maintains a registry of bit flags carried in the PCEP RP
object as defined in [PCEP]. IANA is requested to assign a new bit object as defined in [RFC5440]. IANA is requested to assign a new bit
flag as follows: flag as follows:
Bit Hex Name Reference Bit Hex Name Reference
Number Number
15 0x000100 Path Key (P-bit) [This.I-D] 15 0x000100 Path Key (P-bit) [This.I-D]
7.4. New NO-PATH-VECTOR TLV Bit Flag 7.4. New NO-PATH-VECTOR TLV Bit Flag
IANA maintains a registry of bit flags carried in the PCEP NO- IANA maintains a registry of bit flags carried in the PCEP NO-
PATH-VECTOR TLV in the PCEP NO-PATH object as defined in [PCEP]. PATH-VECTOR TLV in the PCEP NO-PATH object as defined in [RFC5440].
IANA is requested to assign a new bit flag as follows: IANA is requested to assign a new bit flag as follows:
Bits Number Name Flag Reference Bits Number Name Flag Reference
1 PKS expansion failure [This.I-D] 1 PKS expansion failure [This.I-D]
8. Normative References 8. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[PCEP] Vasseur, J.P., Le Roux, J.L., Ayyangar, A., Oki, E., [RFC5440] Vasseur, J.P., Le Roux, J.L., Ayyangar, A., Oki, E.,
Ikejiri, A., Atlas, A., Dolganow, A., "Path Computation Ikejiri, A., Atlas, A., Dolganow, A., "Path Computation
Element (PCE) communication Protocol (PCEP)", draft-ietf- Element (PCE) Communication Protocol (PCEP)", RFC 5440,
pce-pcep, work in progress. March 2009.
9. Informative References 9. Informative References
[RFC3209] Awduche, Berger, Gan, Li, Srinivasan and Swallow, "RSVP-TE: [RFC3209] Awduche, Berger, Gan, Li, Srinivasan and Swallow, "RSVP-TE:
Extensions to RSVP for LSP Tunnels", RFC 3209, December Extensions to RSVP for LSP Tunnels", RFC 3209, December
2001. 2001.
[RFC4655] Farrel, Vasseur & Ash, "A Path Computation Element (PCE)- [RFC4105] Le Roux, J., Vasseur, JP., Boyle, J., "Requirements for
Based Architecture", RFC 4655, August 2006.
[RSVP-PKS] Bradford, R., Vasseur, J.P., Farrel, A., "RSVP Extensions
for Path Key Support", draft-bradford-ccamp-path-key-ero,
work in progress.
[RFC5152] Vasseur, J., et al "A Per-Domain Path Computation Method
for Establishing Inter-Domain Traffic Engineering (TE)
Label Switched Paths (LSPs)", RFC 5152, Fenruary 2008.
[BRPC] Vasseur, J., et al "A Backward Recursive PCE-based
Computation (BRPC) procedure to compute shortest inter-
domain Traffic Engineering Label Switched Path", draft-
ietf-pce-brpc, work in progress.
[RFC4105] Le Roux, J., Vasseur, JP, Boyle, J., "Requirements for
Support of Inter-Area and Inter-AS MPLS Traffic Support of Inter-Area and Inter-AS MPLS Traffic
Engineering", RFC 4105, June 2005. Engineering", RFC 4105, June 2005.
[RFC4216] Zhang, R., Vasseur, JP., et. al., "MPLS Inter-AS Traffic [RFC4216] Zhang, R., Vasseur, JP., et. al., "MPLS Inter-AS Traffic
Engineering requirements", RFC 4216, November 2005. Engineering requirements", RFC 4216, November 2005.
[RFC4655] Farrel, Vasseur, & Ash, "A Path Computation Element (PCE)-
Based Architecture", RFC 4655, August 2006.
[RFC5152] Vasseur, JP., et al "A Per-Domain Path Computation Method
for Establishing Inter-Domain Traffic Engineering (TE)
Label Switched Paths (LSPs)", RFC 5152, Fenruary 2008.
[RFC5298] Takeda, T., et al, "Analysis of Inter-domain Label [RFC5298] Takeda, T., et al, "Analysis of Inter-domain Label
Switched Path (LSP) Recovery", RFC 5298, August 2008. Switched Path (LSP) Recovery", RFC 5298, August 2008.
[RSVP-PKS] Bradford, R., Vasseur, JP., Farrel, A., "RSVP Extensions
for Path Key Support", draft-ietf-ccamp-path-key-ero,
work in progress.
[BRPC] Vasseur, JP., et al "A Backward Recursive PCE-based
Computation (BRPC) procedure to compute shortest inter-
domain Traffic Engineering Label Switched Path", draft-
ietf-pce-brpc, work in progress.
[PCEP-MIB] Kiran Koushik, A., and Stephan, E., "PCE communication [PCEP-MIB] Kiran Koushik, A., and Stephan, E., "PCE communication
protocol (PCEP) Management Information Base", draft- protocol (PCEP) Management Information Base", draft-
kkoushik-pce-pcep-mib, work in progress. ietf-pce-pcep-mib, work in progress.
[RBNF] Farrel, A., "Reduced Backus-Naur Form (RBNF) A Syntax Used [RBNF] Farrel, A., "Reduced Backus-Naur Form (RBNF) A Syntax Used
in Various Protocol Specifications", draft-farrel-rtg- in Various Protocol Specifications", draft-farrel-rtg-
common-bnf, work in progress. common-bnf, work in progress.
10. Acknowledgements 10. Acknowledgements
The authors would like to thank Eiji Oki, Ben Campbell, and Ross The authors would like to thank Eiji Oki, Ben Campbell, and Ross
Callon for their comments on this document. Callon for their comments on this document.
11. Authors' Addresses 11. Authors' Addresses
Rich Bradford (Editor) Rich Bradford (Editor)
Cisco Systems, Inc. Cisco Systems, Inc.
1414 Massachusetts Avenue 1414 Massachusetts Avenue
Boxborough, MA - 01719 Boxborough, MA - 01719
USA USA
EMail: rbradfor@cisco.com EMail: rbradfor@cisco.com
J.-P Vasseur Jean-Philippe Vasseur
Cisco Systems, Inc. Cisco Systems, Inc.
1414 Massachusetts Avenue 1414 Massachusetts Avenue
Boxborough, MA - 01719 Boxborough, MA - 01719
USA USA
EMail: jpv@cisco.com EMail: jpv@cisco.com
Adrian Farrel Adrian Farrel
Old Dog Consulting Old Dog Consulting
EMail: adrian@olddog.co.uk EMail: adrian@olddog.co.uk
Full Copyright Statement
Copyright (c) 2008 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
All IETF Documents and the information contained therein 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 THEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Intellectual Property Intellectual Property
The IETF Trust takes no position regarding the validity or scope of The IETF Trust takes no position regarding the validity or scope of
any Intellectual Property Rights or other rights that might be any Intellectual Property Rights or other rights that might be
claimed to pertain to the implementation or use of the technology claimed to pertain to the implementation or use of the technology
described in any IETF Document or the extent to which any license described in any IETF Document or the extent to which any license
under such rights might or might not be available; nor does it under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any represent that it has made any independent effort to identify any
such rights. such rights.
skipping to change at line 920 skipping to change at page 19, line 20
considered to be definitive versions of these Legal Provisions. considered to be definitive versions of these Legal Provisions.
For the avoidance of doubt, each Contributor to the IETF Standards For the avoidance of doubt, each Contributor to the IETF Standards
Process licenses each Contribution that he or she makes as part of Process licenses each Contribution that he or she makes as part of
the IETF Standards Process to the IETF Trust pursuant to the the IETF Standards Process to the IETF Trust pursuant to the
provisions of RFC 5378. No language to the contrary, or terms, provisions of RFC 5378. No language to the contrary, or terms,
conditions or rights that differ from or are inconsistent with the conditions or rights that differ from or are inconsistent with the
rights and licenses granted under RFC 5378, shall have any effect and rights and licenses granted under RFC 5378, shall have any effect and
shall be null and void, whether published or posted by such shall be null and void, whether published or posted by such
Contributor, or included with or in such Contribution. Contributor, or included with or in such Contribution.
Disclaimer of Validity
All IETF Documents and the information contained therein 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 THEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Full Copyright Statement
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your
rights and restrictions with respect to this document.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s)
controlling the copyright in such materials, this document may not
be modified outside the IETF Standards Process, and derivative
works of it may not be created outside the IETF Standards Process,
except to format it for publication as an RFC or to translate it
into languages other than English.
 End of changes. 24 change blocks. 
59 lines changed or deleted 38 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/