[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
All,
draft-andersson-mpls-g-chng-proc-00.txt seems to be addressed at a
noble goal of bringing some order to new applications and extensions
of the (G)MPLS protocols. However, as Deborah, Kireeti, and Scott
have observed, the way it is written it seems to hinder rather than
help the process of collaborating with other Standards Developement
Organizations(SDOs) and doesn't provide a good way to deal with and respond
to liaison statements, which is the avenue by which many of these
requests will arrive from other SDOs.
It speaks well for the protocols that others will find applications
of them beyond the scope for which they were originally designed, and
even outside the scope of areas addressed by the IETF. The document as
written creates impediments to the ability to apply, and extend as
necessary, these protocols to new problem spaces. I think it would be
a far better goal to promote the reuse and widest application of these
protocols, and to try to enable these new applications through a
process that keeps some order to the applications and extensions of
the protocols.
As noted, biggest flaw seems to be the way in which the document deals
with new applications or requirements identified by external standards
organizations. In addition to not recognizing that this information may
come to IETF via liaison statements, the document seems not to consider
the fact that there may be a valid application that is outside of the
scope of IETF (and in the scope of another standards development
organization) to which the (G)MPLS protocols may be applied, and for
which the (G)MPLS protocols may require extension. By insisting that
every possible extension be done internally in IETF, the IETF either
(1) Extends the scope of its work without bound; or (2) Needlessly
restricts the application of its protocols. Neither one of these is
good for IETF or for the Standards Development community at large.
One reality that this draft fails to recognize is that, while IETF may
be able to say "no" to standardizing something proposed by an individual,
it does not have the ability (or the right) to say "no" to something
proposed by another Standards Development Organization. As a practical
matter, the IETF is not the only place where something can be standardized.
If the IETF creates impediments to applying IETF protocols to
the application space of another standards development organization,
there is really nothing that the IETF can do to prevent that the other
organization standardizes something themselves. The result would tend
to be a proliferation of (G)MPLS "like" protocols instead of a coherent
suite of protocols with broad applicability. This result would not be
good for the IETF or the industry in general.
A better approach would be for the IETF to PROMOTE the use of its
protocols for new applications, and, when another Standards Development
Organization wishes to apply (G)MPLS protocols to an application domain
outside of the scope of IETF, that IETF will (1) assist with the development
of any necessary extensions; and (2) to facilitate documentation of
such new applications and extensions in a central place (e.g., by
informational RFC, even for extensions that are developed outside of
IETF) and to insure that code points are assigned in a coherent manner
through IANA to avoid collisions where different extensions may use
the same code points to indicate different things.
I think that this could lay the groundwork for a much more constructive
collaborative relationship between the IETF and other Standards Development
Organizations than the draft as it stands.
The difference in flavor for what I am proposing is that IETF should
try to position itself as a Clearinghouse for (G)MPLS protocol extensions
rather than as a Gatekeeper for (G)MPLS protcol extensions.
What I have included below are some specific proposed text changes to
try to change the flavor of the current draft to try to accomplish this.
One final question regarding the applicability of this draft: The
sub-IP area is still classified as a temporary area, and it seems
that this particular procedure that will not be valid as written if
remaining sub-IP work is returned to the "native" IETF areas. I
don't have any specific suggestion as to how to solve this problem.
My specific text proposals follow below.
Regards,
Steve
Specific text proposals are as follows:
=======================================================================
Abstract
Original Text:
This memo describes the process through which individuals, working
groups and external standards bodies can influence the development of
MPLS and GMPLS standards. With respect to standardization, this
process means that (G)MPLS extensions and changes can be done through
the IETF only, the body that created the (G)MPLS technology. The
IETF will not publish a (G)MPLS technology extension RFC outside of
the processes described here.
_______________________________________________________________________
Proposed New Text:
This memo describes the process through which individuals, working
groups and external standards bodies can influence the development of
MPLS and GMPLS standards.
MPLS and GMPLS technology has attracted the interest of individuals
and other Standards Development Organizations (SDOs) to apply and,
where necessary, extend the protocols to cover problems and
application spaces beyond those for which the protocols were
originally designed. This speaks well for the architecture of the
protocols that they can find such widespread application, and it
is highly desirable to find ways to reuse and extend existing protocols
rather than inventing new protocols to address these other problem
areas.
The challange going forward is to find ways to maximize the opportunities
for reuse of these protocols, while trying to maintain architectural
integrity of the protocols themselves. This draft outlines a proposal
for such a process.
==========================================================================
Terminology:
Add:
problem statement liaison
a formal liaison statement from another Standards Development Organization (SDO)
that initiates the discussion on extending the (G)MPLS protocols. This
liaison will generally include a detailed problem description and a set of
requirements that the (G)MPLS protocols need to meet to solve the problem.
Such a liaison statement may contain a draft or approved document from
the originating standards organization that characterizes the problem,
indicating the level of agreement or approval that such a document has
acheived in the originating organization.
Supplement existing definition:
requirement evaluating working group (rewg) -
in the process descreibed below, the Working Group charged with the
task of evaluating a certain problem statement and a certain set of
requirements is termed the rewg. The focus of this group is somewhat
different for the cases described here based on whether the problem
statement and requirements came from an individual or another Standards
Development Organization (SDO): in the individual case, the group may focus
on assessing the validity of the requirements. In the case of a problem
statement or requirements coming from an SDO, the other SDO may already
have decided that the problem statement and requirements are valid for
their application space, so the focus is directed more toward evaluation
of whether IETF should be involved in developing the solution to that
problem.
==========================================================================
Section 2.1 Overview
The existing diagram should be labeled "Procedure for initiation of New
Applications and/or Extensions to (G)MPLS Protocols by Individuals".
Even for individuals, there seems to be a missing "shortcut" from the
document procedure. It seems to be assumed that we have already developed
complete, perfect solutions to everything within the current charter,
and not allow for the possibility that there is some missing element or
overlooked requirement that may require a (G)MPLS extension that is
within the current charter. This may require a line directly from the
"review by wg chairs and ad's" box to the "IETF WG process" box to indicate
the path taken where the problem statement is considered to fall entirely
within the current charter.
An additional diagram should be included labeled "Procedure for
initiation of New Applications and/or Extensions to (G)MPLS protocols
by other Standards Development Organizations (SDOs)"
+---------+
|problem |
|statement|<--------------------------------------------- Originating
|liaison | SDO |
+---------+ ^ |
|discusson | |
|on mailing | |
Vlist | |
+---------+ | |
|review by| NACK | |
+-|WG chairs|--------------+ | |
| | and ADs | | | |
| +---------+ | | |
| |request IESG/IAB | | |
| |to appoint rewg | | |
| |and charter | | |
| Vreq eval | +-------------------+ | |
| +---------+ +-------->|liaison indicating | | |
| |IESG/IAB | +-------->|out of scope or |----->| |
| |decision | | +---->|interest for IETF | | |
| +---------+ | | +-------------------+ | |
| |rewg chartered | | | |
| |to work on | | | |
| Vproblem statement | | +-------------------+ | |
| +---------+ NACK | | |liaison explaining | | |
+>|rewg req |--------------+ | |how problem can be |----->| |
+-| eval |----------------------->|solved with | | |
| +---------+ no change reqd | |existing protocol | | |
| | | | +-------------------+ | |
| | | ACK | | |
| | +------------------------------+ | |
| V | | | |
| +---------+ | v | |
| |AD review| | +-------------------+ | |
| +---------+ | |liaison accepting |------+ |
| |request to IESG/ | |new work item | |
| |IAB to approve | +-------------------+ |
| Vcharter changes | ^ |
| +---------+ NACK | | +------------+ |
| |IESG/IAB |------------------+ | | Externally | |
| |decision |----------------------------+ | Developed |<---+
| +---------+ ACK | Solution |
| |wg chartered to +------------+
| |work solution |
| V v
| +---------+ +------------+
+-|IETF WG |----/ /----> stds track RFC | IANA code |
|process | | points |
+---------+ +------------+
^ |
| v
solutions info RFC
ID
=========================================================================
Section 2.2 - Change title to:
2.2. Changes or Extensions to (G)MPLS Protocols Initiated by Individuals
could also consider deleting item 4 of 2.2.4 since new section 2.3 is
proposed to handle proposals from other SDOs. item 4 of 2.2.4 would only
be valid in the case of an individual proposing a new problem to be solved
by extending (G)MPLS protocols that IETF decides would be better addressed
in another standards group. IETF could send a liaison to the other group
with the suggested problem. This case may not be important enough to
spell out explicitly in the document.
=========================================================================
Add new section 2.3:
2.3. Changes or Extensions to (G)MPLS Protocols Initated at the request of
another Standards Development Organization (SDO)
2.3.1. Initiating changes or extensions to (G)MPLS Protocols
If a Standards Development Organization (SDO) wishes to apply the
(G)MPLS protocols to a new application problem space, or sees
a need to extend the (G)MPLS protocols to support the requirements for
that new application, they may inform the IETF in one of the following
manners:
- An internet draft may be produced explaining the problem they are
trying to solve and, if applicable, why the existing (G)MPLS protocols
must be extended to address this problem. A note from the authors
should be sent to the relevant mailing lists to initiate discussion.
- An SDO (particularly those SDOs with whom ISOC/IETF have a
formal relationship, e.g, see RFC 3356 or ITU-T A.sup3, and ITU-T
Rec. A.4 regarding the relationship and communication method with
ITU-T) may also be communicated via a formal liaison or communication
statement. Such a statement is posted via a link from
http://www.ietf.org/IESG/liaison.html and advertised by the iesg
secretariat (who posts the incoming liaison) via the mailing
list to initiate discussion.
The mailing list to use should be Area mailing list and, if known,
the WG mailing list for the WG that will likely be the requirement
evaluation working group. In the case of discussion initiated from
an incoming liaison statement, the liaison may be addressed to a
specific Area or Working Group and notification should me made to
the indicated mailing lists accordingly.
Note concerning work initiated as a result of a liaison statement:
Often a liaison statement that indicates that it is for action will
indicated a deadline. The ADs and WG chairs should be diligent to
make sure that a reply liaison is generated by the requested date,
even if all that can be reported by that date is current status or
a positive acknowledgement of receipt of the information. When the
IETF chooses to undertake work as a result of an incoming liaison,
regular reports of progress should be made via reply liaisons
including anticipated time frames for completion of the work. In
this way, the originating SDO can assess whether they can wait for
an IETF solution or should pursue other avenues.
2.3.2. Problem statement review
The MPLS and CCAMP working group chairs in conjunction with the Area
Directors will determine if the particular problems raised in the
Internet Draft or Incoming Liaison should be evaluated by a working
group. This decision will be based on mailing list discussion. If
the decision is that a requirement evaluation is warranted a decision
is taken on which working group should act as requirement evaluation
working group (rewg).
In the case where the decision is that the IETF will proceed with
further examination of these requirements, the originating SDO should
be informed of this decision in a reply liaison.
In the case where the decision is that the IETF will not proceed
with further requirements evaluation, the "dustbin" which would have
been the result for an individual submission is not an option for
the case where the problem satement and requirements have already
been accepted by another SDO. Since the other SDO has already
accepted the problem statement and requirements, the likelihood is
that this will lead to a standardized solution whether or not IETF
chooses to be involved. At the same time, IETF has an interest in
the long term integrity of the protocol, and can choose one of two
options:
- Even though the particular problem may be out of scope for IETF,
participants may have insight which would assist in the solution to that
problem. For the integrity of the protocol, it is certainly best if
similar problems are solved in similar ways, and since the IETF should
have the broadest view of all applications of the protocol, they are
in a position to offer helpful advice to the other SDO about how to
solve it. This information should be collected from the aforementioned
email discussion and sent to the other SDO in a reply liaison.
- The IETF is not in a position to offer any advice or insight as
to how the problem can be solved. In this case, the IETF should indicate
to the other SDO via a reply liaison that the IETF cannot help them with
the problem, and it is up to the other SDO to define any solution.
In either of case, the reply liaison to the originating SDO should
encourage them to document their additional application or protocol
extension via an informational RFC, (to keep the most complete possible
library of extensions in one place), and to have any protocol code points
assigned via IANA to insure that there are no cases where the same
protocol code points might mean different things in the context of
different extensions developed by different SDOs. This documentation
would also enable the IETF to have a repository of extensions that
would enable it and others to assess relationships between extensions.
Any two extensions might:
- be complementary and be usable at the same time
- co-exist at the same time but it would make sense to only use one or
the other at a time
- not co-exist in an implementation but share a common base
2.3.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 modificiations for the Working Group
to the IESG and the IAB. If the IESG and IAB approve of the charter
changes the Working Group can then update its charter and start the
work to study the requirements and the problems described in the
Liaison statement.
2.3.4. Problem statement study
The rewg will study the problem statement liaison statement and based
on the evaluation, generate a response to the originating SDO and, if
further work is to be undertaken within IETF, make such a recommendation
to the IESG/IAB. The recommendation may be:
1 that no extensions to the (G)MPLS protocols are needed since the
problem can be solved by the protocols as they exist. In this case,
the WG chairs shall coordinate generating a liaison statement back
to the originating SDO explaining how their problem can be solved
with the current protocols.
2 that there is no interest in extending this protocol in IETF.
Note that in the individual submission case (section 2.2.4) IETF
is in the position to decide not to continue the work. However,
in the case of work initiated due to a liaison from another SDO,
the other SDO has already decided that there is a problem for
which a standardized solution should be pursued. If IETF decides
at this point not to pursue a standardized solution to the
problem proposed by the incoming liaisons, a reply liaison is
needed at this point with the same information content as discussed
in section 2.3.2 if the ADs and WG chairs had decided not to
pursue a standardized solution within IETF.
In cases 1 and 2, IETF will not publish a standards track RFC to
address the problem. However, should the originating SDO standardize
its own solution, IETF will facilitate documenting that extension
via an informational RFC and assignment of code points via IANA so
that there is no conflict between this extension and those that may
arise from other sources.
3 that the problem is of interest to IETF and the IETF is interested
in developing extensions to the (G)MPLS protocols to address the
problem. If the problem falls within the current charter,
the normal WG process can be followed at this point. A reply
liaison should be generated to the originating SDO indicating
IETFs intent to accept the work and pursue a solution.
If the problem requires extensions to the charter of the appropriate
working group and the ADs agree, the proposal will be brought
before the IESG and the 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 adopting a final set of
requirements to be forwarded to the working group that will handle
the specification of the protocol changes.
If the ADs or IESG/IAB do not agree to the charter extensions,
a reply liaison should be sent to the originating SDO as in item
2 above.
If a charter revision is agreed, a liaison should be sent to the
originating SDO informing them of the revised charter and the
intent to pursue the work.
The rewg will study and clarify the requirements, merging them with
others if warranted. The resulting requirements should be verified
with the originating SDO via liaison, or other method is appropriate
for that SDO. With concurrence from the originating SDO, the result
is published as a requirements RFC. When the IESG approves
publication of the requirements RFC it will add it as a new task to
the protocol specifying Working Group charter.
The protocol specifying working group will then develop the modifications
or extensions to the (G)MPLS protocols needed to fulfil the requirements.
In the case that the originating liaison has indicated any work or
progress in the originating SDO to develop a protocol solution, that
work shall be taken into account by the protocol specifying working
group. To the extent that sound decisions have been made by the
originating SDO, this should be used as the basis for the work in IETF.
If errors are found, these shall be brought to the attention of the
originating SDO via a liaison statement. Every effort shall be made
to make sure that either the protocol is developed in one place, or
the results are aligned if two specifications cannot be avoided.
========================================================================
Section 4 (obviously):
Add:
RFC 3471
RFC 3472
RFC 3473
RFC 3477
RFC 3478
RFC 3479
RFC 3480
========================================================================
References
Add:
[RFC3356]
Internet Engineering Task Force and International
Telecommunication Union - Telecommunications Standardization Sector
Collaboration Guidelines. G. Fishman, S. Bradner. August 2002.