Hi, Adrian,
The high-level bit is that I am now happy with the document, with the
changes you propose (I'm not the one who has to be happy, but that's ONE set
of last call comments gone).
I deleted everything that we agreed on, just so you could see what's left.
You might not change anything beyond your first e-mail, but in a couple of
places, I wasn't clear on what I was saying, and in a couple of places, I
need to punt to ADs for guidance (and not just about this document, relax).
Thanks for getting back so quickly. I can still remember what I was thinking
last time.
See you in Prague,
Spencer
From: "Adrian Farrel" <[EMAIL PROTECTED]>
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.
Dear Brian, cc: Bill and Ross,
Please note that this document is longer than it needs to be because no one
outside the IETF can reasonably figure out our process, so Adrian has to
describe it for them, but also please note that this draft is targeted for
publication as a BCP, and the procedures described here overlap with other
BCPs, so it's likely to conflict with new BCP text over time, and is even
more likely to conflict with ION text as you describe more WG and IESG
procedures in IONs - and I Would Have Thought that in the event of a tie,
BCP text would trump ION text, if process BCPs are to have any meaning after
IONs enter common use. Sigh.
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.
Ah. The focus on document origins makes much more sense than the focus on
participants, because there's no overlap in the document origins.
Perhaps "The process describes how individual draft submissions, working
group drafts, and inputs from external standards bodies influence the
development of the MPLS and GMPLS standards", as the first sentence?
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?
Dear Brian, Ross, and Bill,
I'm NOT the genius of IANA allocation process. Any guidance here?
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.
OK, but it seems like you guys are going to a lot of trouble to avoid having
to rely on good will for everything else (not arguing, just wondering if you
can head off trouble here - answer may be "no").
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.
OK - I was worried about having a couple of months delay while charters are
added to IESG agendas, sent out for external review, added to IESG agendas,
... but that's really not much time in the life of an SDO, is it?
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.
Sorry if I'm not being clear. I was wondering why the previous section was
"should", and this is now "MUST" - having "must" in the previous section
made more sense to me. You had a previous note about the "should" I was
thinking of allowing IETF to say "sure, go ahead and good luck", so I can
live with this text.
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.
This text makes more sense now that I understand you are telling people who
don't understand our process how IANA works. I'm OK with it.
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.
Dear Bill and Ross, cc: Brian,
Grrr. Adrian is caught between saying WGLC="we think we know what the answer
is, but it could change" and saying RFC Editor queue="we knew what the
answer was at some point in the past, but couldn't tell you then because it
could have changed". I know that the fairly-new IESG guidelines for document
handling timelines is shorter than two years, and I know the RTG area has
been reducing their backlog.
Want to tell him that two year hiatuses (hiatii?) are a memory of the Bad
Old Days? :-) The current text will probably generate a "but you TOLD US
that it had been approved in WGLC!!!" conversation sooner or later.
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.
Ah. Then should this be saying, "if you work on a solution anyway, we still
reserve the right to review it"? In legalese, of course.
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.
:-) I can imagine why...
Have a lovely American Thanksgiving (much like Bastille Day - even if you
don't celebrate it, there IS a July 14th on the calendar in most countries
:-)
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
