One document matched: draft-andersson-rtg-gmpls-change-00.txt
Network Working Group L. Andersson
Internet-Draft Acreo AB
Expires: May 23, 2005 A. Farrel
Olddog consulting
G. Swallow
Cisco Systems
K. Kompella
Juniper Networks
A. Zinin
Alcatel
November 22, 2004
MPLS and GMPLS Change Process
draft-andersson-rtg-gmpls-change-00.txt
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
RFC 3668.
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 May 23, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
Andersson, et al. Expires May 23, 2005 [Page 1]
Internet-Draft MPLS and GMPLS Change Process November 2004
The MPLS and GMPLS protocol suites have become quite popular for a
growing number of applications and deployment scenarios. One result
of this popularity is a large number of suggestions for modifications
and extensions.
The IETF needs to be flexible and responsive in how it handles these
suggestions, and has a responsiblity to supervise the growth and
evolution of MPLS and GMPLS protocols.
This memo describes the process through which individuals, working
groups and external standards bodies can influence the development of
the MPLS and GMPLS standards. This process means that extensions and
changes to protocols specified by these working groups can only be
made through the IETF, the body that created the (G)MPLS
((Generalized) Multiprotocol Label Switching) technologies.
Andersson, et al. Expires May 23, 2005 [Page 2]
Internet-Draft MPLS and GMPLS Change Process November 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Managing the (G)MPLS technology in the IETF . . . . . . . . . 5
2.1 Multiprotocol Label Switching Working Group . . . . . . . 5
2.2 Common Control & Measurement Plane Working Group . . . . . 6
2.3 MPLS and CCAMP cooperation . . . . . . . . . . . . . . . . 7
2.4 Other (G)MPLS technology working groups . . . . . . . . . 7
2.5 Routing Area and Routing Area working groups . . . . . . . 8
2.6 Organizations outside the IETF . . . . . . . . . . . . . . 8
2.7 Terminology . . . . . . . . . . . . . . . . . . . . . . . 9
3. MPLS and GMPLS Change Process . . . . . . . . . . . . . . . . 10
3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2 Description . . . . . . . . . . . . . . . . . . . . . . . 11
3.2.1 Initiating changes or extensions to (G)MPLS
protocols . . . . . . . . . . . . . . . . . . . . . . 11
3.2.2 Problem statement review . . . . . . . . . . . . . . . 11
3.2.3 Charter update . . . . . . . . . . . . . . . . . . . . 11
3.2.4 Problem statement evaluation . . . . . . . . . . . . . 12
3.2.5 Not accepted requirements . . . . . . . . . . . . . . 13
4. Extensibility and Architecture . . . . . . . . . . . . . . . . 15
5. (G)MPLS protocols . . . . . . . . . . . . . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.1 Normative References . . . . . . . . . . . . . . . . . . . . 19
8.2 Informative References . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . 20
Andersson, et al. Expires May 23, 2005 [Page 3]
Internet-Draft MPLS and GMPLS Change Process November 2004
1. Introduction
This memo describes the process through which individuals, working
groups and external standards bodies can influence the development of
MPLS and GMPLS related standards. This process means that (G)MPLS
extensions and changes can only be done through the IETF, the body
that created the (G)MPLS technology. In particular the MPLS and/or
CCAMP Working Groups need to be involved in the process.
The IETF will not endorse publishing (G)MPLS technology extension
RFCs that did not follow the processes described here. If
publication of individual Internet-Drafts requesting extensions or
changes the (G)MPLS protocols by the RFC Editor are requested they
will looped back through the process described in this document.
IANA has allocation policies for all of the code point registries it
manages. In many cases, IANA will refer back to the IETF when asked
to make an allocation. In the case of changes or extensions to the
(G)MPLS protocols, the process described in this document will be
used to judge whether or not a code point allocation that should be
made.
The (G)MPLS technology is developed in two main tracks in the IETF.
"MPLS" refers to the work done for packet switched networks, while
the "GMPLS" refers to the efforts to apply the MPLS protocols to all
types of networks. Though GMPLS by definition is a superset of MPLS,
the term "(G)MPLS" is used to indicate both of these tracks. A
terminology section that covers the use of terms and concepts used in
this document is found in Section 2.7.
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 RFC 2119 [RFC2119].
Andersson, et al. Expires May 23, 2005 [Page 4]
Internet-Draft MPLS and GMPLS Change Process November 2004
2. Managing the (G)MPLS technology in the IETF
This section outlines the applicability of the (G)MPLS change process
specified in this document. It lists the key IETF working groups
developing the (G)MPLS technology, examples of IETF working groups
using the (G)MPLS technology and possible parties interested in
using, extending or changing the (G)MPLS technology. A terminology
local to this document that will be used in specifying the change
process is also included.
Currently there are two working groups in the IETF Routing Area
working on the (G)MPLS technology. The Multiprotocol Label Switching
(MPLS) working group and the Common Control and Measurement Plane
(CCAMP) working group.
This section (Section 2) gives an overview of the work these IETF
working groups are currently chartered to do, and some of the working
groups that use the (G)MPLS technology. It should be remembered that
the IETF environment is highly dynamic, working groups and whole
areas come and go. The overview of the IETF structure is only a
snapshot in time.
2.1 Multiprotocol Label Switching Working Group
The Multiprotocol Label Switching (MPLS) working group is
responsible for standardizing the base technology for using label
switching and for describing the implementation of label-switched
paths over various packet and frame-based link level technologies.
The working group charter includes procedures and protocols for the
distribution of labels between routers, as well as encapsulations,
operation and management, traffic engineering and multicast
considerations.
When the (G)MPLS technology was broken out to be developed by
multiple working groups, one of the assumptions was that for changes
and extensions to the existing MPLS protocols the MPLS working group
should accept requirements, relevant to protocols specified by the
MPLS working group or for work items on the working group charter,
from other working groups. The MPLS working group also accepts
requirements from other sources, e.g., individuals or external
standards bodies. Such requirements SHALL be sent to the working
group in the form of Internet-Drafts.
Documents that propose extensions or changes to the MPLS protocols,
e.g. those that specify new MPLS methods or new MPLS encapsulations
MUST be handled according to the processes described in this document
by the MPLS working group or by the MPLS Designated Expert (a.k.a.
caretaker) appointed by the IESG if the MPLS working group has been
Andersson, et al. Expires May 23, 2005 [Page 5]
Internet-Draft MPLS and GMPLS Change Process November 2004
closed.
One exeception to this rule is when other IETF working groups has
been appointed, in accorance with the process descrbide in this
document, to handled extensions and/or changes to the protocols
specified by the MPLS working group.
2.2 Common Control & Measurement Plane Working Group
The IETF Common Control and Measurement Plane (CCAMP) working group
coordinates the work within the IETF defining a common control plane
and a separate common measurement plane for ISP and SP core tunneling
technologies. This includes, but is not limited to, defining
signaling protocols and measurement protocols such that they support
multiple physical path and tunnel technologies using input from
technology- specific working groups such as the MPLS working group;
protocol-independent metrics and parameters for describing links and
paths that can be carried in protocols. The technology that the
CCAMP Working group focuses on is sometimes called Generalized MPLS
(GMPLS), indicating that CCAMP addresses a generalized technology,
where labels are defined in such a way that they will be compatible
with the technology they are transported over. While the MPLS
working group focuses on packet- and frame-switched technologies, the
CCAMP working group work focuses on common methods accross a broad
spectrum of switching technologies. In this respect GMPLS can be
viewed as a superset of MPLS.
When the (G)MPLS protocols were broken out to be developed by
multiple working groups one of the assumptions was that the CCAMP
working group should take input in the form of requirements from
other working groups. The CCAMP Working group is also open for
requirements from other sources, e.g., individuals or external
standards bodies. Such requirements SHALL be sent to the working
group in the form of Internet-Drafts.
Documents that propose extensions or changes to protocols that have
been specified by the CCAMP working group, e.g., documents that
specify new GMPLS methods and new GMPLS encapsulations MUST be
handled according to the processes described in this document by the
CCAMP working group or by the GMPLS Designated Expert (a.k.a.
caretaker) if the CCAMP working group has been closed.
One exeception to this rule is when other IETF working groups has
been appointed, in accorance with the process descrbide in this
document, to handled extensions and/or changes to the protocols
specified by the CCAMP working group.
Andersson, et al. Expires May 23, 2005 [Page 6]
Internet-Draft MPLS and GMPLS Change Process November 2004
2.3 MPLS and CCAMP cooperation
From time to time the MPLS and CCAMP working groups decide to divide
work between themselves in a way that does not always strictly follow
the split between the working groups as defined in the working groups
charter. This is the case, e.g. for P2MP TE LSP's, where the MPLS
working group is specifying requirements and base technology for all
of the (G)MPLS area.
An entity or individual that wishes to propose extensions or changes
to (G)MPLS should first decide to which Working Group (MPLS or CCAMP)
it will bring the proposal. However, the MPLS and CCAMP WG chairs,
in conjunction with their Area Directors, MAY redirect the proposal.
2.4 Other (G)MPLS technology working groups
There have been several working groups working on (G)MPLS
requirements, e.g., the IP over Optical (IPO) working group and the
Internet Traffic Engineering Working Group (te-wg). These working
groups have not specified any protocols, but have been a source of
requirements to be considered by the (G)MPLS working groups. Other
working groups, e.g. the Bidirectional Forwarding (BFD) working
group also use the (G)MPLS protocols and mechanisms, and when this
involve extending and/or changing the protocols specified by the
(G)MPLS working groups, this has to be submitted to the working group
that originally specified the protocol in the form of an
Internet-Draft.
The Layer 2 VPN (L2VPN) and Layer 3 VPN (L3VPN) working groups have
been chartered to specify a limited number of solutions for Provider
Provisioned VPN's. Both working groups are in the Internet Area. It
is assumed that the work of L2VPN and L3VPN does not include
specifying new protocols, however, should protocol changes and/or
extensions be made to protocols specified by the (G)MPLS working
groups, these changes and/or extensions SHALL be submitted to the
(G)MPLS working group that originally specified the protocol in the
form of an Internet-Draft.
The Pseudo Wire Emulation End to End (PWE3) working group is a
working in the Internet Area that also uses the (G)MPLS protocols in
its specifications. Should the PWE3 specifications require extension
and/or changes to the (G)MPLS protocols these changes and/or
extensions SHALL be submitted to the (G)MPLS working group that
originally specified the protocol in the form of an Internet-Draft.
It is assumed that the change process for the MPLS and CCAMP Working
groups, specified in this document, will be applicable or at least
adaptable to other (G)MPLS technology working groups if such a need
Andersson, et al. Expires May 23, 2005 [Page 7]
Internet-Draft MPLS and GMPLS Change Process November 2004
should arise.
If the requirements for a proposal to change or extend (G)MPLS
protocols falls under the purview of a (G)MPLS technology Working
Group, the review process MUST involve both the technology Working
Group(s) that understand the requirements as well as the Working
Group(s) that shepherd protocol changes.
Should this be the case, that other working group needs to explicitly
state this in a Inernet-Draft and take it through the normal IESG
review process.
The set of (G)MPLS technology working groups, as indeed IETF working
groups in general, changes over time. A list of the current set of
working groups and areas will be found at
http://www.ietf.org/html.charters/wg-dir.html
2.5 Routing Area and Routing Area working groups
The change process specified in this document, if this is found
beneficial, could be extended to any and all Routing Area working
groups, and thus be applicable to all the protocols specified by
those Routing Area working groups.
Should this be the case those working groupss, or the Routing Area
AD's, need to state this in an Internet-Draft and take it through the
normal IESG review process.
2.6 Organizations outside the IETF
A number of standards development organizations (SDOs) and industrial
forums are using or referencing the (G)MPLS protocols in their
specifications. Some of these organizations have formal liaison
relationships with the IETF, and sometimes these liaison
relationships go back several years. The IETF exchanges information
with these organizations about what is happening on both sides,
including plans and schedules.
However, if any organization outside the IETF thinks they need to
extend and/or change an existing (G)MPLS protocol or create a new
protocol in the (G)MPLS area, a description of the requirement that
brought the organization to this conclusion MUST to be submitted to
the (G)MPLS working groups in the form of Internet Drafts. Such
Internet-Drafts SHALL be handled in a timely manner according to the
process described in this document. Note that the Internet Draft
must detail the requirements. This Internet-Draft MAY be accompanied
by a separate Internet Draft that proposes a way to meet the
requirements. The IETF is not required to accept the way suggested
Andersson, et al. Expires May 23, 2005 [Page 8]
Internet-Draft MPLS and GMPLS Change Process November 2004
to meet the requirements even if the IETF agrees that the requirement
is valid.
2.7 Terminology
o (G)MPLS working groups -
in this document the term (G)MPLS working groups is used to
indicate the MPLS and the CCAMP working groups, and any future
working group specifically chartered by the IESG to work on the
development or extension of the (G)MPLS protocols.
o (G)MPLS technology working groups -
the (G)MPLS working groups plus any working groups chartered to
specify requirements on the (G)MPLS protocols and working groups
using the (G)MPLS protocols in their specifications, see sections
Section 2.1, Section 2.2 and Section 2.4 for examples of (G)MPLS
technology working groups.
o (G)MPLS protocols -
in this document the term (G)MPLS protocols is used to indicate
the union of the protocols specified by the (G)MPLS working
groups.
o requirement evaluating working group (rewg) -
in the process described below, the working group charged with the
task of evaluating a certain problem statement and a certain set
of requirements is termed the rewg
o protocol specifying working group (pswg)-
in the process described below the working group chartered to
specify certain changes and/or extensions to the (G)MPLS protocols
are called - pswg.
o problem statement Internet-Draft -
the draft that initiates the discussion on changing or extending
the (G)MPLS protocols. This Internet Draft needs to include a
detailed problem description and a set of requirements that the
(G)MPLS protocols need to meet to solve the problem.
o solutions Internet-Draft -
a specification on how to change or extend the (G)MPLS protocols
to meet the requirements in the problem statement Internet-Draft -
this is not required but MAY be useful.
Andersson, et al. Expires May 23, 2005 [Page 9]
Internet-Draft MPLS and GMPLS Change Process November 2004
3. MPLS and GMPLS Change Process
This section includes Figure 1 in Section 3.1 that summarizes the
(G)MPLS change process, and Section 3.2 that discusses the process in
more detail.
3.1 Overview
+-------+ +---------+ +---------+
| prob |discussion |review by| ACK | IESG | ACK
| statem|---------->|wg chairs|------------->| IAB |-------+
| id |on mailing |and ad's | request to |decision | |
+-------+ list +---------+ IESG/IAB to +---------+ |
| appoint rewg | |
| NAK and charter |NAK rewg |
| req eval | chartered|
| | to work|
V | on prob|
| statement|
|response | | |
|to the | | |
|prob | <---------------+ |
+->|statement| <-------------------+ |
| +---------+ | |
| ^ | |
|NAK | NAK | |
| +-----------------+ | V
| | | NAK +-------+
+--------+ +-------+ +------| rewg |
| IESG | ACK | AD | ACK | req |
+-----------| IAB |<-------------- |review |<----------| eval |
| wg |decision| request to | | | |
|chartered +--------+ IESG/IAB to +-------+ +-------+
|to work approve wg
|solution charter changes
| +---------+
| | IETF |
+--------->| WG |-----/ /----> RFC
| process |
+---------+
^
|
solutions
ID
Andersson, et al. Expires May 23, 2005 [Page 10]
Internet-Draft MPLS and GMPLS Change Process November 2004
Figure 1
The figure above gives an overview of the (G)MPLS change process. A
more detailed discussion on the key elements in the process is found
below.
3.2 Description
This section discusses in more detail how the (G)MPLS change process
works, what is expected from individuals or organizations that wants
to extend and/or change the (G)MPLS and the responsibilities of the
(G)MPLS working groups, the Routing Area and the IETF in general.
3.2.1 Initiating changes or extensions to (G)MPLS protocols
Anyone who intends to use one of the existing (G)MPLS protocols, but
thinks that it will not satisfy their needs MUST write an Internet-
Draft (ID) explaining the problem they are trying to solve and why
the existing (G)MPLS protocols will not work. This Internet-Draft -
the problem statement ID - MUST include a detailed set of
requirements that (G)MPLS would need to meet to solve the particular
problem. The ID MUST also describe in detail any security issues
that arise from meeting the requirements. This Interenet-Draft SHALL
be sent to the IETF as an individual Ineternet-Draft and after it is
published the authors should send a note to the appropriate mailing
list to start discussion on the problems discussed in the
Internet-Draft. The mailing list to use will in most cases be the
Routing Area maililng list, as this is the Area containing working
group that has specified the protocol being changed and that will
likely be the rewg. The IESG or the Routing Area ADs may decide to
use a specific working group mailing list for this discussion.
3.2.2 Problem statement review
The MPLS and CCAMP working group chairs in conjunction with the
Routing Area ADs will determine if the particular problems raised in
the Internet-Draft should be evaluated by a working group. This
mailing list discussion will be an essentail part in forming a
decission. If the decision is that a requirement evaluation is
warranted a decision is taken, by the ADs, on which working group
should act as the rewg.
3.2.3 Charter update
If the chairs and the ADs both feel that the particular problems
should be added to the MPLS or the CCAMP Working Group charter the
ADs will propose specific charter modifications for the Working group
to the IESG and IAB. If the IESG and the IAB approve of the charter
Andersson, et al. Expires May 23, 2005 [Page 11]
Internet-Draft MPLS and GMPLS Change Process November 2004
changes the working group can then update its charter and start the
work to evaluate the requirements and the problems described in the
Internet-Draft.
In a separate Internet-Draft the authors of the problem statement (or
anyone else) MAY describe a set of changes to the (G)MPLS protocols
that would meet the requirements. This Internet-Draft would not be
considered by the rewg as part of the requirement evaluation, but no
discussions on progressing the draft will be held until a working
group has been chartered to work on a solution, i.e. one of the
possible outcomes of the process described in this document. The
IETF is not required to accept the solutions proposed in such an
Internet-Draft.
There may in fact exist more than one Internet-Draft trying to meet
the requirements specified in the problem statement draft. If this
is the case neither draft will be considered in the requirment
evaluation process. They will all be held until a working group has
been chartered to work on a solution and then all solutions drafts
will be brought to the chartered working group.
3.2.4 Problem statement evaluation
The rewg will evaluate the problem statement ID and based on the
evaluation make a recommendation to the IESG/IAB. The recommendation
may be:
o that it is not a problem that falls within the remit of the IETF
or could be solved by extending or changing the (G)MPLS protocols
o that no changes or extensions to the (G)MPLS protocols are
justified because the problem is not a general enough one.
In these two cases the IETF will not publish an RFC that attempts to
get around the decision.
The IETF works based on a rough consensus within the working group,
i.e. even if a proposal is not reject based on the criteria above,
it is still possible for the working group to decide that it is not
something that should be done in the working group.
o that the problem is real and extensions to the (G)MPLS protocols
are justified, and that a work item should be added to the charter
of the appropriate working group - if the ADs agree then they will
bring the proposal before the IESG and IAB. If the IESG (with IAB
advice) agrees that the task should be added to that particular
charter then the rewg can work on it with the aim of developing a
Andersson, et al. Expires May 23, 2005 [Page 12]
Internet-Draft MPLS and GMPLS Change Process November 2004
final set of requirements to be forwarded to the working group
that will handle the specification of the protocol changes.
In this case the rewg will evaluate and refine the requirements,
merging them with other rewuirments if warranted. The result of
these deliberations will be captured in a requirements RFC. The IESG
may add a new task to the pswg charter prior to the publication of
the requirements RFC, as soon as the problem space is sufficently
understood.
The protocol specifying working group will then develop the
modifications or extensions to the (G)MPLS protocol needed to fulfill
the requirements.
If such a requirements document is added to a working group charter
and if a proposed solution has previously been published as an
Internet-Draft, the pswg may evaluate the proposed solution - but
there is no requirement that any particular proposal be adopted.
The (G)MPLS working groups are REQUIRED to protect the architectural
integrity of the (G)MPLS protocols and MUST NOT extend the GMPLS
architecture with features that do not have general use beyond the
specific case - they also MUST NOT modify the architecture just to
make some function more efficient at the expense of simplicity or
generality.
o that the problem is real and that they would be solved with
extensions to the (G)MPLS protocols, but that this for some reason
is not best done within the IETF, but within some other SDO. The
IETF might in such a case come to an agreement with this SDO that
it MAY specify the protocol extensions and that these will be
described in a ID sent to the IETF for review and eventually be
published as an RFC.
In this case the IETF enters into some limited commitments towards
the SDO undertaking the protocol specification, e.g. support in
reviewing and publishing the work.
3.2.5 Not accepted requirements
Whenever a problem statement Inter-Draft is not accepted this should
be clearly communicated to the authors of the draft. This
communication could take any of several forms; it might be obvious
after author(s) has presented the problem statement at a working
group meeting that the requirements will be accepted it is considered
enough capturing this in the meeting minutes; if working groups
Andersson, et al. Expires May 23, 2005 [Page 13]
Internet-Draft MPLS and GMPLS Change Process November 2004
chairs and/or ADs takes the concensus decision meaning that the
requirments will not be accpted this decision should be sent to the
working group mailing list, with a copy to the authors; if the
problem statement were accompanied by a liaison or communication a
response should be sent to the organization originating the liaison
or communication.
Andersson, et al. Expires May 23, 2005 [Page 14]
Internet-Draft MPLS and GMPLS Change Process November 2004
4. Extensibility and Architecture
In an idealized technical design, the extensibility design would be
self-contained, and it would be inherent that new extensions and new
headers would naturally have an architectural coherence with the
original protocol.
However, this idealized vision has not been attained in the world of
standards tracks protocols. Implications for interoperability can be
addressed by capabilities negotiation rules. The effects of adding
features that overlap or that deal with a point solution and are not
general are much harder to control with rules. Therefore the (G)MPLS
technology calls for this architectural guardianship by its Working
Groups.
We encourage other protocol working groups with highly extensible
protocols to review whether they need more coordination of extensions
as in the (G)MPLS case.
Andersson, et al. Expires May 23, 2005 [Page 15]
Internet-Draft MPLS and GMPLS Change Process November 2004
5. (G)MPLS protocols
The set of RFC³s that constitutes the (G)MPLS protocols are the
standards track RFCs from the (G)MPLS working groups. We don't
supply a list of these RFCs since these numbers are increasing rather
quickly since there are new IDs going through working group last call
and awaiting publication in the in the RFC-Editors queue.
For the purpose of extending and changing any protocols specified in
Experimental RFCs developed by the (G)MPLS working groups they are
considered to be part of the (G)MPLS protocols.
Andersson, et al. Expires May 23, 2005 [Page 16]
Internet-Draft MPLS and GMPLS Change Process November 2004
6. Security Considerations
Note: Needs to be filled in
Andersson, et al. Expires May 23, 2005 [Page 17]
Internet-Draft MPLS and GMPLS Change Process November 2004
7. Acknowledgements
The input given by Bill Fenner, Scott Bradner and Bert Wijnjen has
been useful and detailed.
Andersson, et al. Expires May 23, 2005 [Page 18]
Internet-Draft MPLS and GMPLS Change Process November 2004
8. References
8.1 Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2 Informative References
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
Authors' Addresses
Loa Andersson
Acreo AB
EMail: loa@pi.se
Adrian Farrel
Olddog consulting
EMail: adrian@olddog.co.uk
George Swallow
Cisco Systems
EMail: swallow@cisco.com
Kireeti Kompella
Juniper Networks
EMail: Kireeti@juniper.net
Alex Zinin
Alcatel
EMail: zinin@psg.com
Andersson, et al. Expires May 23, 2005 [Page 19]
Internet-Draft MPLS and GMPLS Change Process November 2004
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2004). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Andersson, et al. Expires May 23, 2005 [Page 20]
| PAFTECH AB 2003-2026 | 2026-04-21 01:05:32 |