Good morning Spencer,
Thanks for the review.
Summary: This document is on the right track for publication as a BCP, but
some work is still needed.
Comments:
I have lots of questions, but most are requests for greater clarity - I
would not expect Brian to DISCUSS based on most of the questions I listed
in this review.
If I could make any single suggestion, it would be to remove anything that
describes "business as usual" in the working group process ("As with all
Internet-Drafts produced by a working group, ..."), for two reasons - the
focus should be on what happens that is NOT "business as usual", and the
detailed description here will be very fragile - for example, if the RTG
ADs decided they would accept directorate reviews instead of conducting
their own reviews, this procedure would be out of step. It adds no value
to say that the IESG MUST ballot any Internet-Draft forwarded for
publication by a working group.
The problem I have in documenting this is that it is partly aimed at
consmption by external parties that do not understand the IETF process and
are looking for a single description of how their work will be handled. I'll
think some more about this and if we can find something coherent to
reference instead of redescribing the IETF process we will do that.
Abstract
The process allows individuals, IETF working groups, and external
standards bodies to influence the development of the MPLS and GMPLS
standards. When possible, existing liaison relationships are used.
Spencer: it just seems odd to list individuals and IETF working groups
separately here (and in the Introduction). After reading further, I
wondered if the point was not that IETF working groups *other than the
(G)MPLS working groups* could influence the development of these
standards, but that wasn't clear from this text, either.
Hmmm. Actually the point may be to target other SDOs without saying so :-(
What we are trying to say is "everyone is on an even playing field". No-one
is held back, and no-one is advanced.
We wanted to cover:
- individual draft submissions
- working group drafts
- material from other SDOs.
1. Introduction
This document recognizes that the Multiprotocol Label Switching
(MPLS) and Generalized MPLS (GMPLS) protocol families were created
within the IETF and constitute significant protocol suites that are
strategic to the development of the Internet. They should not be
extended or varied without IETF review, and that should preferably
only be extended within the IETF process.
Spencer The last sentence doesn't parse well for me, "preferably" seems
weak, and I'm not sure why it says "extended" and not "varied". Suggest
"These protocol families should only be extended or varied within the IETF
process." - and even this seems inconsistent with MUSTs later in the
document.
Changed to...
These protocols should
not be extended or varied without IETF review, and they should
only be extended within the IETF process.
The point of diversion from "MUST" is that the procedures defined later
allow the IETF to say: "OK, you are free to make the change."
The IETF will not endorse the publication of any MPLS or GMPLS
protocol or technology extensions in RFCs or other documents where
Spencer: suggest "until the process described here has been followed" -
you're not saying you won't endorse them under any circumstances, right?
but only that you won't endorse the documents without considering them as
described in this document.
Right.
the process described here have not been followed. If publication of
individual Internet-Drafts describing extensions or changes to the
MPLS or GMPLS protocols is requested of the RFC Editor the documents
will be returned to the process described in this document using the
mechanism described in [RFC3932].
IANA is responsible for managing many codepoints registries including
those for MPLS and GMPLS protocols. These registries have specific
allocation policies that IANA uses in order to determine whether
codepoints can be allocated and which codepoints to allocate. In many
cases, the rules require IANA to refer back to the IETF when asked to
make an allocation. In the case of changes or extensions to the MPLS
or GMPLS protocols, IANA will use its normal documented procedures to
Spencer: got a reference for the "normal documented procedures" you have
in mind?
Hmmmm :-)
I used to have a description of what IANA was required to do, but I got
warned off redefining IANA procedures.
Is RFC2434 any use?
judge whether or not a code point allocation should be made.
2.2 Other (G)MPLS Technology Working Groups
Problem statements and requirements for (G)MPLS technology have been
produced by several working groups in addition to the MPLS and CCAMP
working groups. For example, the IP over Optical (IPO) working group
Spencer (nit): "Examples are" (need a verb) ...
OK
and the Internet Traffic Engineering working group (TEWG). These
working groups have not specified any protocols, but have been a
source of problem statements and requirements to be considered by the
(G)MPLS working groups.
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 VPNs. Both working groups are in the Internet Area. The
work of the L2VPN and L3VPN working groups does not include
specifying new protocols, however, protocol changes and extensions
to the (G)MPLS protocols may be needed. If so, the procedures
specified in this document are applicable.
The Layer 1 VPN (L1VPN) working group is chartered to specify
mechanisms necessary for providing layer 1 VPN services
(establishment of layer 1 connections between CE devices) over a
GMPLS-enabled transport service-provider network. Protocol extensions
required for L1VPN will be done in cooperation with MPLS, CCAMP,
OSPF, IS-IS, IDR, L3VPN, and other WGs where necessary. That is, the
Spencer: you guys are the experts, but L2VPN is conspicuous by its absence
in this list - it's named previously, so perhaps this is an accidental
omission?
Deliberate. The L1VPN working group doesn't appear to have any protocol
overlap with L2VPN. Curious but true. L3 and L1 are very similar, but L2 is
off in its own set of weeds.
L1VPN will not develop GMPLS protocol extensions in isolation, but
will develop requirements and propose extensions that will be
reviewed and approved by the (G)MPLS working groups.
2.3 Organizations Outside the IETF
A number of standards development organizations (SDOs) and industrial
forums use or reference the (G)MPLS protocols in their
specifications. Some of these organizations have formal or less
Spencer: either "formal or informal" or "more or less formal", I think.
OK
formal liaison relationships with the IETF [RFC4052]. The IETF
exchanges information with these organizations about what is
happening on both sides, including plans and schedules, using liaison
statements [RFC4053]. More details about the cooperation relationship
between the IETF and the ITU-T can be found in [RFC3356].
The procedures in this document are applicable to all organizations
outside the IETF whether or not they have formal liaison
relationships with the IETF. If any organization outside the IETF
has a requirement, or believes it may have a requirement, for
Spencer: I'd remove ", or believes it may have a requirement," - just
seems too legalistic.
:-)
extensions or modifications to the (G)MPLS protocols then the
procedures in this document apply.
2.4 Terminology
This section defines terms for use in the context of this document.
o (G)MPLS protocols
The set of RFCs that constitutes the (G)MPLS protocols are the
standards track RFCs from the (G)MPLS working groups (see below).
A list of these RFCs is not supplied here since new RFCs are
produced from time to time.
Spencer: I'm visualizing an ugly race condition here (with someone who
starts extending something before it's been published as an RFC).
"Standards-track specifications"?
Yes. This race condition exists with PWE3, BFD, and L3VPN.
We are going to have to handle it (are already handling it) through good
will.
For the purpose of extending and changing any protocols specified
in Experimental, Informational, or BCP RFCs developed by the
(G)MPLS working groups, those protocols are considered to be part
of the (G)MPLS protocols.
Spencer: this is just odd. Are there any protocols defined in these types
of documents today? If so, and you're going this direction - what about
Historic? but I think you're really saying "ANY specification from the
(G)MPLS working groups".
Yes. "any specification" would be better. The list we had just grew.
o Requirement evaluating working group (rewg)
Spencer (nit) - "rewg" and "pswg" would look less odd in caps, and they
are acronyms ...
Can do.
The rewg is the IETF working group charged with the task of
evaluating a specific set of requirements and the associated
problem statement.
3. Summary of Procedures
Whenever there is reason to believe that a particular problem may be
solved by use of or extensions to the (G)MPLS protocols, a
preliminary investigation phase may be used to discuss the
requirements with the IETF. This may lead to an understanding that
the problem is already solved, is outside the scope of the IETF, or
requires more investigation possibly leading to changes to the
(G)MPLS protocols.
Spencer: It seems odd that the requirements statement Internet-Draft is
mentioned here, but the problem statement internet-draft has not been
mentioned previously in this section.
OK
Whenever any extension or change to the (G)MPLS protocols is desired,
a requirements statement must be produced and must be submitted to
IETF as an Internet-Draft.
Spencer: the following text would be a lot more readable as a list of
bullets.
Yup.
In assessing the requirements statement I-D, the IETF may determine:
that the requirements can be satisfied without modifications to the
(G)MPLS protocols; that the requirements are not sufficiently general
to warrant a change to the (G)MPLS protocols; that the requirements
justify a change to the (G)MPLS protocols that will be created by the
IETF or within another organization; that the requirements might not
be possible to satisfy without violating the (G)MPLS architecture in
a way that would harm the (G)MPLS technology; or that the
requirements should be combined with other requirements to solve a
more general problem or solve the same problem in a more flexible
way.
The solutions that are developed within the IETF may be sourced from
external organizations and presented for review, discussion,
modification, and adoption as Internet-Drafts. Such solutions drafts
may be presented to the IETF in advance of the completion of the
requirements work, but all solutions will compete through the normal
IETF process with other proposed solutions, and none will be adopted
as an IETF working group draft until the requirements are agreed by
the rewg chairs to be stable and, in any case, not before the pswg
has a charter item to cover the solutions work.
Spencer: "has a charter item" is awfully formal - could the last condition
be that an AD AGREES to add a charter item to cover the solutions work, if
no charter item already exists? I do see WGs that run under this type of
informal working arrangement with ADs for new milestones.
Oooh: rat-hole!
I don't believe WGs should run in this mode. I believe WG chartering is by
IETF consensus under IESG guidance, so individual ADs are not so powerful
(which is possibly why they allow things to happen without re-charetering
:-).
I really don't want to go down the path of this discussion in this I-D, and
I'm happy to require charter items (!= milestones) before work starts. The
current text, I believe, covers us for charter items that already exist.
4. MPLS and GMPLS Change Process
Anyone who intends to use one of the existing (G)MPLS protocols, but
thinks that it will not satisfy their needs MUST use the procedures
Spencer: I know that the text in previous sections was not normative, but
it contained lower-case "should". Suggest that the text in previous
sections changes to lower-case "must"?
Don't get it.
There is no 2119 language before section 4. First para of section 4 is also
non-2119. From then on, everything is procedural and is in 2119 language.
described in this document. Changes or extensions to the (G)MPLS
protocols MUST NOT be made by any other mechanism. The IETF MUST NOT
endorse any publications (including RFCs whether on the Standards
Track, Informational, or Experimental) that change or extended the
(G)MPLS protocols except for those that arise through the correct
execution of the procedures in this document. The IETF MUST NOT
endorse any IANA action that allocates (G)MPLS protocol codepoints
except as a result of actions arising from the correct execution of
the procedures in this document.
Spencer: wow. Does the IETF usually adopt these kinds of self-restraints?
Nope.
And this lack of self-restraint has led us to blindly allocate codepoints
for harmful (deliberately harmful?) changes to the core protocols.
Actually, when I say no, I really mean yes :-)
We have plenty of self-restraints wrt codepoint allocation. For example: the
definition of "IETF Consensus" for a code point is pretty much a constraint.
4.1 Flow Diagram
Figure 1 is presented to give a visual overview of the process. It
does not contain all of the possible interactions of procedures, and
the text in the subsequent sections should be used for a definitive
description of the process.
Spencer: Use of "ACK" and "NACK" in Figure 1 is cute, but "YES" and "NO"
seems clearer, I think.
Thanks. Yes.
4.2.1 Preliminary Investigation
This step SHOULD be carried out informally on the mailing list of the
rewg or on the Routing Area discussion mailing list and MAY be
Spencer: I wish there was one place you could point to for these
discussions - multiple rewgs are fine, but the conversation could be on
the Routing Area discussion mailing list, so monitoring the rewgs you care
about isn't sufficient.
Agree. But it is "generally accepted" (hah!) that you have to subscribe to
the specific WG mailining lists you care about, and the parent area
mailining list, and the IETF discussion mailing list. It is a bother, but I
don't know how you can otherwise be sre to capture everything important if
it comes out as a new discussion point. Fortuantely:
- we are not requiring to follow the IETF discussion list because everything
here falls under Routing
- the Routing discussion list is very quiet.
initiated by any individual, group of individuals, external
organization, or IETF working group.
A possible outcome of this preliminary investigation is that the
requirements and problem are understood, but agreed to be out of
scope for the IETF. Alternatively it may be that the problem can be
solved with existing protocols. The full list of outcomes from the
preliminary investigation phase are identical to those for the
requirements statement evaluation phase described in section 4.2.2,
but the requirements statement evaluation phase MUST form part of the
process if the requirements are understood and the IETF would like to
develop protocol solutions - the process cannot move direct form the
Spencer: s/direct form/directly from/
Yes and no.
from/form is one of my favorite finger dibbles.
"directly" refers to time: i.e. immediately.
"I will do it directly" == "I will do it at once"
"direct" refers to space: i.e. without intervening steps
"I will go there direct" == "I will not stop in the sports bar to catch the
second half of the game"
preliminary investigation pahse to the development of solutions.
Spencer: s/pahse/phase/
Yes
4.2.2 Requirements Statement Evaluation
After discussion on the IETF mailing lists, the appropriate IETF
working group chairs and the Routing Area Directors MUST decide
whether the requirements will be formally evaluated by the IETF, and
MUST deliver a response to the requirements statement I-D.
Spencer: The following text says pretty clearly how the IETF wg chairs and
RTG ADs respond to a formal liaison, but I didn't see any discussion of
how they respond in the absence of a formal liaison.
Yes.
If the requirements statement I-D is brought to the IETF through a
formal liaison, the IETF MUST respond using one of the following
answers in a formal liaison reply. If a formal liaison was not used
the response SHOULD be delivered using one of the following answers
in an email copied to the appropriate mailing lists.
b. Requirements understood, but judged to be out of scope for the
IETF. In this case, the originator of the requirements can work
on on requirements and solutions and will not be impeded by the
Spencer: s/on on/on/
on and on and on?
IETF. The IETF may request to be kept informed of progress.
4.2.3 Chartering the Rewg
Spencer: this section actually seems to be about modifying the rewg's
charter, not chartering the rewg. Perhaps "Reviewing the Requirements
Statement I-D"?
"Chartering or Rechartering the REWG"
In many cases the problem covered by the requirements statement I-D
will fall within the scope of the existing charter of a working
group. In this case, the Routing Area Directors SHOULD designate the
working group as the rewg and pass the requirements statement I-D to
the working group for evaluation.
Spencer: it was not obvious to me how the case is handled when a new
requirements evaluation working group must be created - is anyone in
particular responsible for developing a proposed charter?
Under unusual circumstances the Routing Area Directors MAY decide to
charter a new working group to act as the REWG. In this case, the ADs
are responsible for drafting the charter of the new working group and
MUST follow the procedures set out in the previous paragraph.
4.2.5 AD Evaluation of Completed Requirements Statement I-D
As with all Internet-Drafts produced by a working group, the ADs MUST
review the completed requirements statement I-D produced by the rewg
to determine its fitness for publication. At their discretion, the
ADs MAY use an Area Directorate and/or other subject matter experts
to assist them in this review
Spencer: missing period after "review".
Yes.
4.2.7 Solutions Work
Once the pswg has been identified and (re-)chartered as necessary and
the requirements statement I-D has been approved by the IESG, the
pswg can start work on solutions following the normal IETF process.
Solutions I-Ds MAY be prepared externally (such as within an external
organization) or within the IETF, submitted to the IETF for
publication, and introduced to the pswg for consideration. Such I-Ds
MAY be submitted at earlier stages in the process to assist the rewg
in its development and discussion of the requirements, but no I-D
will be formally considered as a solutions I-Ds until the pswg has a
charter item that covers the work and the rewg chairs are confident
that the requirements are stable. Even at this stage in the process,
the IETF makes no guarantees that an externally produced solutions
I-D will form the basis of the pswg solutions I-D, but the pswg MUST
consider such an I-D as a possible solution I-D.
Spencer: is there any potential for misunderstanding by an SDO who might
expect that "MUST consider" requires the I-D to be "baseline text", become
a WG draft, etc? (The text is clear to me, but I think I understand how
the IETF works) In particular, we're a lot more casual about big changes
to individual drafts than we are about big changes to working group
drafts, or at least, we should be.
MUST consider such an I-D for review and revision as a possible solution
I-D.
Where the requirements originated from an external organization, the
pswg SHOULD regularly communicate its progress using a formal liaison
process if one exists. This communication SHOULD also be used to
request review input and comment on the development of the solutions
I-D. The solutions I-D MUST be communicated to the originating
organization during working group last call for final review against
the requirements. When the solutions I-D is complete (normally upon
completing working group last call and/or on entering the RFC
Editor's queue) the pswg MUST inform the originating organization of
the completed solution.
Spencer: "when the solutions I-D is complete" probably isn't WGLC...
suggest "on entering the RFC Editor's queue" as the only triggering
condition.
I'm inclined to agree in principle, but I am worried abot the two year
hiatus between the two events.
5. Rejecting Requirements Statements I-D
The requirements can be rejected at various stages of the process as
described in the previous sections. The person or grouping that makes
Spencer: I think this is "or group"?
yes
the rejection is responsible for generating an explanation of the
rejection and MUST follow the process described in this section.
5.1 Reasons for Rejection
The requirements statement I-D can only be rejected using one of the
following reasons. Each reason MUST be stated with the acceptable
next steps as described here.
- Requirements not understood. At the early stage of evaluation of
the requirements statement I-D before the rewg has been tasked with
performing a full evaluation and completing the requirements
statement I-D or during the optional preliminary investigation it
is not clear what the requirements are for or what the problem
being addressed is.
Spencer: the "not understood" explanation is way too complex. Perhaps
"Either during preliminary investigation or during evaluation of the
requirements statement I-D, it wasn't clear what the requirements are, or
what the problem being addressed is."
OK
- Out of scope for the IETF. Many stages of this process may
determine that the requirements are out of scope for the IETF. In
this case, the IETF MUST NOT constrain the authors of the
requirements statement I-D permission to work on a solution.
Spencer: "constrain ... to work ..." isn't quite right. "prevent ... from
working ..."? And I'm not sure what this is saying - "permission to work
on a solution in other SDOs"? Or something else?
Yes. I got confused trying to write in American. I'll put it into English
and leave the RFE Editor to sort out the detail.
What is intended is a passive version of "grant permission to work in
another SDO". That is, "not block work in another SDO"
- No protocols extensions or changes are needed. At some stage in the
evaluation of the requirements it may become clear that they can
all be met through appropriate use of existing protocols. In this
case no further evaluation of the requirements is required, but the
IETF MUST explain how the protocols can be used to meet the
requirements and MAY cooperate with the authors of the requirements
Spencer: these IETF MUST/MAY statements can require real work, for which
"IETF" isn't quite right - you need a stuckee. Does this become something
like "the rewg chairs or their delegates"?
Ah yes. In my experience it is usually me :-(
I guess we should stick it to the REWG and by default the REWG chairs.
statement I-D in the production of an Applicability Statement
Internet-Draft or a Profiles Internet-Draft that explains precisely
how the existing protocols can be used to meet the requirements.
- Insufficient support within the IETF. Although the work described
within the requirements statement I-D is within scope for the IETF,
and despite the support of the originators of the requirements
statement I-D on the rewg mailing list, the chairs of the rewg have
determined that there is insufficient support in the rewg to
complete requirements statement I-D. In this case, the IETF MUST
grant the authors of the requirements statement I-D permission to
work on a solution. The solution SHALL be presented to the IETF
for review and possible publication as an Informational or
Experimental RFC, and the IETF SHALL NOT block applications to IANA
for codepoints.
Spencer: the SHALL and SHALL NOT in the last sentence don't seem quite
right. If this is saying "if you work on a solution anyway, we still
review it", this could be clearer.
Actually, there wasn't any intent to promise review.
- Insufficient support for the work. If the authors of the
Spencer: is this "insufficient support from the requestors"? This could be
clearer. As it is, this category sounds like a superset containing the
previous category.
OK
requirements statement I-D do not make themselves available on the
rewg mailing list for discussion of the requirements or do not
contribute the completion of the requirements statement I-D, the
chairs of the rewg MAY determine that there is insufficient support
for the work and MAY reject the requirements statement I-D. In this
case, the IETF MUST NOT grant permission for the work to be carried
out in any other organization, and MUST NOT endorse the publication
of any changes or extensions to the (G)MPLS protocols and MUST NOT
instruct IANA to allocate any codepoints. The requirements may be
re-introduced by starting the procedure again from the top.
- Satisfying the requirements would break the technology. It is
possible that an assessment will be made that, although the
requirements are reasonable, it is not possible to satisfy them
through extensions or changes to the (G)MPLS protocols without
violating the (G)MPLS architecture in such a way as would break the
(G)MPLS technology. In this case a recommendation will be made that
some other technology be used to satisfy the requirements. See
Spencer: just checking my understanding - there's no expectation that the
IETF make any recommendation about what other technology would be used,
right? If I got this correctly, no change needed.
Yeah. I suppose we could make a suggestion, but we can't guarantee to.
Section 7 for further discussions of the protection of the
integrity of the (G)MPLS technology.
5.2 Actions Upon Rejection
Spencer: this section seems to be "Rejecting a requirements statement
I-D" - the current title isn't clear about whether the actions are taken
by the requestor or the rejecter.
Oh.
Right, that's easy to fix.
Spencer: there are several SHOULDs in this section with no discussion of
why they aren't MUSTs. This seems awkward. ("SHOULD, unless you just
decide not to ...")
Right.
I think I had become tired.
- If the requirements are brought to the IETF as a preliminary
investigation (see Section 4.2.1) through an email exchange then
the response SHOULD be made as an email response and SHOULD be
archived through an IETF email archive.
Spencer: 4.2.1 says "SHOULD be carried out on rewg mailing list or routing
area mailing list", so I think the "SHOULD be archived" can be dropped -
this is required for all IETF working group mailing lists.
Reworded.
The responsibility for the generation of the response lies with the
person, people, or grouping that instigates the rejection. This may
be the IESG, one or more Area Directors, one or more working group
chairs, or a protocol caretaker. In the case of the use of a liaison
Spencer: I was asking "who is the stuckee?" in a previous comment. You
might consider putting a list (perhaps this list) in one place in the
document, and using it by reference, especially in the places where you're
saying "the IETF will ...". The IETF, as a whole, doesn't do much except
express consensus or lack thereof.
Yup. I have gone back to all instances of "the IETF" and applied a little
more focus.
The stuckee does depend on where we are in the process at the time.
I found that "the IETF MUST NOT" is acceptable, but "the IETF MUST" needed
refinement.
relationship, the IETF's liaison manager has responsibility for
ensuring that the procedures in this document, and particularly the
rejection procedures, are followed.
6. Abandonment of the Solutions I-D
Once the solutions work has been started by the pswg, it MAY be
Spencer: this is probably a lower-case "may".
Yes
abandoned before completion. This can happen if the pswg chairs
determine that there is no longer working group support for doing the
work. This could arise, for example, if no-one (including the
originators of the requirements statement I-D) is willing to
contribute to the development of a solutions I-D.
In the event that the solutions work is abandoned by the pswg, the
Area Directors responsible for the pswg MUST be consulted. The
originators of the requirements statement I-D MUST be informed that
the work has been stopped using a mechanism dependent on how the
Spencer: "has been abandoned"? Perhaps good to avoid saying we "stopped"
doing anything?
:-)
requirements were introduced (as discussed in Section 5.2).
7. (G)MPLS Integrity
The (G)MPLS working groups are REQUIRED to protect the architectural
integrity of the (G)MPLS protocols and SHOULD NOT extend the GMPLS
Spencer: this SHOULD NOT seems to beg for an explanation of why it's not
MUST NOT. It's the only SHOULD (NOT) in this section, which seems to be
the "line in the sand" section.
I agree with you, but I'm finding it hard to type "MUST NOT" just in case.
OK. I managed it!
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.
Cheers,
Adrian
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
