IETF Process discussions - next steps

[Brian E Carpenter]

Here are my conclusions from the plenary discussion
and the General Area open meeting at IETF 66.

1. Conclusions from plenary discussion on Newtrk issues
(draft-carpenter-newtrk-questions-00.txt)

A clear theme in the plenary discussion in Montreal was "declare victory."
Unfortunately, in reading the notes and listening to the audio
recording, and reading subsequent emails, it is also clear that
different speakers meant different things by this phrase - anywhere
from clarifying today's standards track, through reducing it to two
or one stages, to simply sitting down and shutting up. Although
on the order of 40 people out of several hundred in the plenary
appeared to believe that formal changes to the standards process
should be made, and some people are ready to do work (thanks!)
there was no firm consensus for a given direction (as there never has
been in the Newtrk WG).

One useful observation was that there is nothing in present
rules and procedures to prevent the writing and publication
of overview standards documents ("ISDs" in Newtrk parlance),
as long as they fit into RFC 2026 rules as Applicability
Statements.

A need was observed for lightweight documentation of the real
world deployment status of individual standards, as concrete
feedback from running code. Again, no rule prevents this today,
but neither do we have guidelines as to the format, status
and indexing of such documents.

My conclusions are that:

1.1. There is insufficient pressure and energy in the community
to justify the effort of reaching consensus on formal changes
to the standards process at this time.

1.2. For complex standards where a normative or informative
overview document would be beneficial, nothing in today's
rules and procedures prevents interested parties from
writing and submitting such documents within the rules set
by RFC 2026, and such efforts should be welcomed.

1.3. The community should be encouraged to produce documentation
of deployment and interoperability of individual IETF standards,
even if there is no proposal to advance them on the standards track.
Such documents should be directed towards efforts to update
IETF standards and/or to document errata and operational issues.
A more systematic framework than today's implementation reports
would be beneficial.

1.4. The newtrk WG should be closed.

2. Conclusion from GenArea mini-BOF on IESG structure and charter.

It seemed clear in the room that people felt there was not a serious
enough problem with RFC 3710 to justify a significant effort.
There was some support for undertaking at least the first step:
* List Tasks that Currently Gate on the IESG
in order to document whether there is in fact a problem worth
solving.

My conclusion is to ask John Leslie to lead a small team to carry out this
very specific task for the information of the community.

3. Conclusion from GenArea mini-BOF on WG Procedures (RFC 2418)

It seems there is some feeling that the RFC is beginning to show
its age, and would be worth updating.

My conclusion is that the best first step is to ask Margaret
Wasserman to lead a small team to survey participants and build
a list of issues that need updating. Of course, any actual
update to RFC 2418 would then have to follow normal IETF
consensus process.

3. Conclusion from GenArea mini-BOF on mailing list management procedures.
(draft-galvin-maillists-00.txt)

It seems clear from recent experience with RFC 3683 that something
needs to happen in this area and that feelings run deep on this issue.
However, the energy to work on this in the community is limited despite
some support in the mini-BOF for doing so.

My conclusion is, as experiments under draft-hartman-mailinglist-experiment
are possible immediately, there is no urgency to start an organized
effort right now - but it should be considered over the coming
months. Meanhwile I would like to ask Jim Galvin to update
his draft according to the discussion, for future reference.

A suggestion was made during the meeting to rapidly declare RFC 3683
obsolete.

Brian Carpenter
General Area Director


.

[Eliot Lear]

Brian,

Your logic omits two substantial problems that NEWTRK was chartered to
address:

* We are not practicing what we preach. The IESG continues to
ignore and violate Section 6.2 of RFC 2026 by not reviewing the
state of PS and DS standards.
* We again do not practice what we preach when we say that there are
three tracks. Running code largely indicates one.

Hence we need an update to indicate what it is we do practice.
Otherwise, particularly for the first item, people can and should
legitimately ask what *other* requirements the IESG finds inconvenient.
Furthermore, it leaves us open to people coming in and saying, "You
don't follow your own process, so please don't hide behind it when you
take an action I don't like." The IESG must correct this issue.

In the process of doing so, we should recognize that the three step
process is obsolete. Anyone who disgrees with that statement is
ignoring the evidence. Our tradition as an organization is to attempt
to rectify our specifications based on running code. Let us please do
so in this instance.

Finally, you have repeatedly failed to heed my recommendation of letting
Scott simply propose an update to the specification. We as an
organization have trusted him and his words for a long time. We are now
in a debacle because the IESG can't seem trust either this working group
or him. And now we are going around endlessly through process hoops.

To say I am utterly disappointed at where we are would be an understatement.

Eliot
.

[Brian E Carpenter]

Eliot,

I specifically do not believe there were any signs of newtrk reaching
a consensus on the first two points you mention and I specifically
do not believe that there is enough interest in the community to
justify a clarification update of 2026.

I wish it were otherwise. I have personally (co)authored several drafts
in this area over the last several years, namely
draft-ietf-newtrk-proposals
draft-carpenter-newtrk-twostep
draft-carpenter-ietf-disputes
draft-carpenter-rfc2026-critique
but without an emerging consensus for specific change we are at the end of
the road.

BTW I have just submitted an update of draft-carpenter-rfc2026-critique
which is somewhat reoriented:

This document discusses how RFC 2026, the current description of the
IETF standards process, operates in practice. Its main purpose is to
document, for information only, how actual practice interprets the
formal rules.

There's a preview at
http://www.geocities.com/be1carpenter/draft-carpenter-rfc2026-critique-02.html

Comments welcome.

Brian

Eliot Lear wrote:
> Brian,
>
> Your logic omits two substantial problems that NEWTRK was chartered to
> address:
>
> * We are not practicing what we preach. The IESG continues to
> ignore and violate Section 6.2 of RFC 2026 by not reviewing the
> state of PS and DS standards.
> * We again do not practice what we preach when we say that there are
> three tracks. Running code largely indicates one.
>
> Hence we need an update to indicate what it is we do practice.
> Otherwise, particularly for the first item, people can and should
> legitimately ask what *other* requirements the IESG finds inconvenient.
> Furthermore, it leaves us open to people coming in and saying, "You
> don't follow your own process, so please don't hide behind it when you
> take an action I don't like." The IESG must correct this issue.
>
> In the process of doing so, we should recognize that the three step
> process is obsolete. Anyone who disgrees with that statement is
> ignoring the evidence. Our tradition as an organization is to attempt
> to rectify our specifications based on running code. Let us please do
> so in this instance.
>
> Finally, you have repeatedly failed to heed my recommendation of letting
> Scott simply propose an update to the specification. We as an
> organization have trusted him and his words for a long time. We are now
> in a debacle because the IESG can't seem trust either this working group
> or him. And now we are going around endlessly through process hoops.
>
> To say I am utterly disappointed at where we are would be an understatement.
>
> Eliot
> .
> newtrk resources:_____________________________________________________
> web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
> mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html
>
.

[Pekka Savola]

On Thu, 10 Aug 2006, Brian E Carpenter wrote:
> I specifically do not believe there were any signs of newtrk reaching
> a consensus on the first two points you mention and I specifically
> do not believe that there is enough interest in the community to
> justify a clarification update of 2026.
>
> I wish it were otherwise. [...]

I wish as well. However, I agree on your reading of the rough
consensus, and I think it's good to put the somewhat tiring process
process to rest (for now, at least).

--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
.

[John Leslie]

Eliot Lear <***@cisco.com> wrote:
>
> * We are not practicing what we preach. The IESG continues to
> ignore and violate Section 6.2 of RFC 2026 by not reviewing the
> state of PS and DS standards.

I'd appreciate input on whether such a task "gates on" the IESG.
RFC 2026 says:
"
" 6.2 Advancing in the Standards Track
"...
" When a standards-track specification has not reached the Internet
" Standard level but has remained at the same maturity level for
" twenty-four (24) months, and every twelve (12) months thereafter
" until the status is changed, the IESG shall review the viability of
" the standardization effort responsible for that specification and the
" usefulness of the technology. Following each such review, the IESG
" shall approve termination or continuation of the development effort,
" at the same time the IESG shall decide to maintain the specification
" at the same maturity level or to move it to Historic status. This
" decision shall be communicated to the IETF by electronic mail to the
" IETF Announce mailing list to allow the Internet community an
" opportunity to comment. This provision is not intended to threaten a
" legitimate and active Working Group effort, but rather to provide an
" administrative mechanism for terminating a moribund effort.

This looks a lot like it should be included in a list of "Tasks that
Currently Gate on the IESG". These are "IESG shall" tasks in a RFC
which is widely considered current and in effect. At first blush, I
would feel obliged to include these.

Comments?

--
John Leslie <***@jlc.net>
.

[Scott Bradner]

> I'd appreciate input on whether such a task "gates on" the IESG.

since its not being done (nor has it been done in the past) I'd say "no"

Scott
.

[Scott W Brim]

Eliot Lear wrote:
> * We are not practicing what we preach. The IESG continues to
> ignore and violate Section 6.2 of RFC 2026 by not reviewing
> the state of PS and DS standards.
> * We again do not practice what we preach when we say that there
> are three tracks. Running code largely indicates one.

Brian E Carpenter wrote:
> I specifically do not believe there were any signs of newtrk
> reaching a consensus on the first two points you mention

There was certainly consensus on the first one. It's a simple fact.
Let's stick to that.

> and I specifically
> do not believe that there is enough interest in the community to
> justify a clarification update of 2026.

... which is to say, there's lots of interest but not enough to
overcome the huge barriers to success.

On 08/10/2006 09:47 AM, Scott Bradner allegedly wrote:
>> I'd appreciate input on whether such a task "gates on" the IESG.
>
> since its not being done (nor has it been done in the past) I'd say
> "no"

... which brings me to why I'm replying. The purpose of the "gates
on" list is to assist thinking about the structure of IETF activity.
The fact that we are not doing something doesn't mean we shouldn't be.
IIRC most people thought standards should go through periodic review,
but we didn't have a good process for doing so. So this item is still
on the list of things which _should_ be done, and the fact that we
don't know how to do it effectively doesn't change that. I believe
this should go on John's list.

swb
.

[James M. Polk]

At 10:18 AM 8/10/2006 -0400, Scott W Brim wrote:
>On 08/10/2006 09:47 AM, Scott Bradner allegedly wrote:
> >> I'd appreciate input on whether such a task "gates on" the IESG.
> >
> > since its not being done (nor has it been done in the past) I'd say
> > "no"
>
>... which brings me to why I'm replying. The purpose of the "gates
>on" list is to assist thinking about the structure of IETF activity.
>The fact that we are not doing something doesn't mean we shouldn't be.
>IIRC most people thought standards should go through periodic review,
>but we didn't have a good process for doing so. So this item is still
>on the list of things which _should_ be done, and the fact that we
>don't know how to do it effectively doesn't change that. I believe
>this should go on John's list.

fully agree


>swb
>.
>newtrk resources:_____________________________________________________
>web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
>mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html
.

[Brian E Carpenter]

Scott W Brim wrote:
> Eliot Lear wrote:
>
>> * We are not practicing what we preach. The IESG continues to
>> ignore and violate Section 6.2 of RFC 2026 by not reviewing
>> the state of PS and DS standards.
>> * We again do not practice what we preach when we say that there
>> are three tracks. Running code largely indicates one.
>
>
> Brian E Carpenter wrote:
>
>>I specifically do not believe there were any signs of newtrk
>>reaching a consensus on the first two points you mention
>
>
> There was certainly consensus on the first one. It's a simple fact.
> Let's stick to that.

Er, yes, what I meant of course was that there was no consensus about
what to do about those phenonema. Sorry about the careless translation
from thinking to typing.

>>and I specifically
>>do not believe that there is enough interest in the community to
>>justify a clarification update of 2026.
>
>
> ... which is to say, there's lots of interest but not enough to
> overcome the huge barriers to success.
>
> On 08/10/2006 09:47 AM, Scott Bradner allegedly wrote:
>
>>> I'd appreciate input on whether such a task "gates on" the IESG.
>>
>>since its not being done (nor has it been done in the past) I'd say
>>"no"
>
>
> ... which brings me to why I'm replying. The purpose of the "gates
> on" list is to assist thinking about the structure of IETF activity.
> The fact that we are not doing something doesn't mean we shouldn't be.
> IIRC most people thought standards should go through periodic review,
> but we didn't have a good process for doing so. So this item is still
> on the list of things which _should_ be done, and the fact that we
> don't know how to do it effectively doesn't change that. I believe
> this should go on John's list.

In any case, when the community (typically but not always a
conscientious WG) decides to aim for DS or STD status, the IESG
approving the implementation reports and the possibly updated RFC
becomes a gating factor.

A related observation is that the doctrine for some years has been
"when a WG is done, close it." An alternative doctrine could be
"when a WG is done, recharter it to nurture its standards and when
appropriate, recommend them for promotion." But in fact, the energy
*is* lacking in most cases, and the IESG has always been scared
of perpetual WGs that do work for work's sake.

Brian
.

[Eliot Lear]

Brian E Carpenter wrote:
>
>
> Scott W Brim wrote:
>> Eliot Lear wrote:
>>
>>> * We are not practicing what we preach. The IESG continues to
>>> ignore and violate Section 6.2 of RFC 2026 by not reviewing
>>> the state of PS and DS standards.
>>> * We again do not practice what we preach when we say that there
>>> are three tracks. Running code largely indicates one.
>>
>>
>> Brian E Carpenter wrote:
>>
>>> I specifically do not believe there were any signs of newtrk
>>> reaching a consensus on the first two points you mention
>>
>>
>> There was certainly consensus on the first one. It's a simple fact.
>> Let's stick to that.
>
> Er, yes, what I meant of course was that there was no consensus about
> what to do about those phenonema. Sorry about the careless translation
> from thinking to typing.

If we simply tackle the first point and ignore the second, the IESG can
say that they are following a documented process. The process, however,
is still a bad one because...
> But in fact, the energy
> *is* lacking in most cases, and the IESG has always been scared
> of perpetual WGs that do work for work's sake.

BINGO. So there are many options to improve matters:

* Simply combine draft and full (e.g., drop draft);
* Drop both draft AND full; or
* Drop both draft and full AND go with ISDs.

I really don't care which one you do but pick one, Brian, and run with
it. The NEWTRK group has done a lot of thought here and would prefer
the latter. All I care is that we be mindful of the words you wrote
just above "BINGO" and that we at least attempt to follow whatever
process we set down.

Eliot
.

[j***@nokia.com]

>If we simply tackle the first point and ignore the second, the
>IESG can say that they are following a documented process.
>The process, however, is still a bad one because...
>> But in fact, the energy
>> *is* lacking in most cases, and the IESG has always been scared of
>> perpetual WGs that do work for work's sake.
>
>BINGO. So there are many options to improve matters:
>
> * Simply combine draft and full (e.g., drop draft);
> * Drop both draft AND full; or
> * Drop both draft and full AND go with ISDs.
>
>I really don't care which one you do but pick one, Brian, and
>run with it. The NEWTRK group has done a lot of thought here
>and would prefer the latter. All I care is that we be mindful
>of the words you wrote just above "BINGO" and that we at least
>attempt to follow whatever process we set down.

I'm with Eliot on this one. I still think we should put our money
where our procedures are. Either follow them, or update them. I would
prefer either 2 or 3 from Eliots list.

Drafts get DISCUSSes if the draft doesn't follow any number of
documented
(and sometimes undocumented) procedures. Could we (the NEWTRK WG) issue

a DISCUSS on the entire IESG about not following 2026?

John Loughney

Too many John's in the this group. Everyone in the Security Area is
Steve, I
guess in the General Area, its John ...

.

[John C Klensin]

--On Thursday, August 10, 2006 9:47 AM -0400 Scott Bradner
<***@harvard.edu> wrote:

>> I'd appreciate input on whether such a task "gates on" the
>> IESG.
>
> since its not being done (nor has it been done in the past)
> I'd say "no"

Hmm. Since the IESG has the option of doing it --indeed a
requirement to do it which they have decided to not take
seriously-- I'd say "yes"... independent of whether that
decision is wise or not. The relevant gate is just
semi-permanently closed.

john



.

[Brian E Carpenter]

John C Klensin wrote:
>
>
> --On Thursday, August 10, 2006 9:47 AM -0400 Scott Bradner
> <***@harvard.edu> wrote:
>
>>> I'd appreciate input on whether such a task "gates on" the
>>> IESG.
>>
>>
>> since its not being done (nor has it been done in the past)
>> I'd say "no"
>
>
> Hmm. Since the IESG has the option of doing it --indeed a requirement
> to do it which they have decided to not take seriously--

I can't stop myself wryly observing that this goes back a long way,
to when Certain Persons Here Present were in the IESG. In other words,
it isn't a frivolous decision by recently appointed ADs, and there's
probably a reason for it.

Brian

I'd say
> "yes"... independent of whether that decision is wise or not. The
> relevant gate is just semi-permanently closed.
>
> john
>
>
>
> .
> newtrk resources:_____________________________________________________
> web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
> mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html
>
.

[John C Klensin]

--On Friday, August 11, 2006 11:58 AM +0200 Brian E Carpenter
<***@zurich.ibm.com> wrote:

>> Hmm. Since the IESG has the option of doing it --indeed a
>> requirement to do it which they have decided to not take
>> seriously--
>
> I can't stop myself wryly observing that this goes back a long
> way,
> to when Certain Persons Here Present were in the IESG. In
> other words,
> it isn't a frivolous decision by recently appointed ADs, and
> there's probably a reason for it.

Of course there is a reason for it. There are probably, by now,
several. But the facts remain that:

(1) the written rules are not being followed.

(2) those rules put the IESG in the critical path

(3) the IESG has not raised a finger to change the rules

(4) the discussion and near/ rough consensus in Newtrk led to a
proposal that would have significantly changed the situation,
but the then-IESG didn't like it, so it got permanently stalled.

IMO, the next move is up to the IESG, and debating the precise
definition of "gating" won't help anyone get to it. And the
only other way to make progress starts with a change in the way
process rules/ changes are reviewed and approved.

john



.

[Pekka Savola]

On Thu, 10 Aug 2006, John C Klensin wrote:
> --On Thursday, August 10, 2006 9:47 AM -0400 Scott Bradner
> <***@harvard.edu> wrote:
>
>>> I'd appreciate input on whether such a task "gates on" the
>>> IESG.
>>
>> since its not being done (nor has it been done in the past)
>> I'd say "no"
>
> Hmm. Since the IESG has the option of doing it --indeed a requirement to do
> it which they have decided to not take seriously-- I'd say "yes"...
> independent of whether that decision is wise or not. The relevant gate is
> just semi-permanently closed.

Well, we recently completed a task of looking at some PS documents and
making quite a few of them Historic.

Are folks interested in continuing that exercise for DS and newer PS
documents? I'd certainly be willing to spend some time in doing so.
That way this doesn't really _need_ to gate on IESG.

--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
.

[John C Klensin]

--On Friday, August 11, 2006 1:09 PM +0300 Pekka Savola
<***@netcore.fi> wrote:

> Well, we recently completed a task of looking at some PS
> documents and making quite a few of them Historic.
>
> Are folks interested in continuing that exercise for DS and
> newer PS documents? I'd certainly be willing to spend some
> time in doing so. That way this doesn't really _need_ to gate
> on IESG.

If the same process is followed as was used for the "decruft"
process, the IESG still has to sign off. That sort of small
team effort may take the IESG (at least temporarily) out of the
critical path, but, if I understand the concept of "gating", it
doesn't change that fact.

john




.

[Spencer Dawkins]

> If the same process is followed as was used for the "decruft" process, the
> IESG still has to sign off. That sort of small team effort may take the
> IESG (at least temporarily) out of the critical path, but, if I understand
> the concept of "gating", it doesn't change that fact.
>
> john

One thing I liked about decruft is that the IESG was delegating all the work
except approval. "Gating" matters, but so does who does most of the work.

I would not be offended to see process change that delegates some approvals,
but delegating work right up to the point of approval doesn't require
process change, and somehow seems to "gate less" on the IESG.

Thanks,

Spencer


.

[John C Klensin]

--On Saturday, August 12, 2006 7:32 PM -0500 Spencer Dawkins
<***@mcsr-labs.org> wrote:

>> If the same process is followed as was used for the "decruft"
>> process, the IESG still has to sign off. That sort of
>> small team effort may take the IESG (at least temporarily)
>> out of the critical path, but, if I understand the concept
>> of "gating", it doesn't change that fact.
>>
>> john
>
> One thing I liked about decruft is that the IESG was
> delegating all the work except approval. "Gating" matters, but
> so does who does most of the work.
>
> I would not be offended to see process change that delegates
> some approvals, but delegating work right up to the point of
> approval doesn't require process change, and somehow seems to
> "gate less" on the IESG.

Spencer,

This is precisely why I wish that, instead of talking about
"gating", we were doing a serious critical path analysis of IETF
workflow(s).

john




.

[Scott W Brim]

On 08/12/2006 22:16 PM, John C Klensin allegedly wrote:
> This is precisely why I wish that, instead of talking about "gating", we
> were doing a serious critical path analysis of IETF workflow(s).

Isn't "talking about 'gating'" part of that? What would you do for a
"serious critical path analysis"?
.

[John C Klensin]

--On Saturday, August 12, 2006 10:30 PM -0400 Scott W Brim
<***@cisco.com> wrote:

> On 08/12/2006 22:16 PM, John C Klensin allegedly wrote:
>> This is precisely why I wish that, instead of talking about
>> "gating", we were doing a serious critical path analysis of
>> IETF workflow(s).
>
> Isn't "talking about 'gating'" part of that? What would you
> do for a "serious critical path analysis"?

It has become clear to me during the last several days of
discussion that we don't have a clear idea / consensus about
what "gating" means. And a critical path analysis might point
the finger at places other than the IESG, while this "gating"
discussion starts with the IESG as the answer and works (IMO)
backwards.

john



.

[Eliot Lear]

Dear All,

As a reminder, the decruft process was as follows:

1. Select a group of Proposed Standards from RFCs numbered less than
2000;
2. Present that list to an open mailing list that has been widely
announced;
3. To remove an entry from the list, someone merely needed to send a
note saying that a particular specification was still necessary
for some reason. We did NO validation of the reasons;
4. Present the trimmed list to other interested parties (e.g., rinse
& repeat);
5. Last call to the IETF (e.g., rinse and repeat); and finally
6. Approval

Possible next steps include any or all of the following:

1. Go on to PS for RFCs 2000 to, say, RFC 3830, which brings us to
two years prior to now, and approximately the same number of
documents as the last time;
2. Take a look at DS for RFCs < 2000;
3. Develop a BCP for the bunch
4. First figure out what to do with the standards process and then
circle back to this.


I prefer (d).

My primary reason for doing this was to allow the IESG to make true use
of PS, such that if something less than useful slips through the cracks
we can catch it in a next pass. Before we advance any of the three
options I would want guidance from the IESG that they would find these
approaches useful. I did so the last time based on an interest from the
IETF chair who co-authored the document and hosted the old-standards
mailing list.

But my agreement with Harald had a second part to it, which said that we
had to make forward progress on fixing the standards track. Obviously
Harald is not in the position he was. However, I once again urge the
IESG to recognize that RFC 2026 needs fixing. We need to evolve as an
organization. It does not bode well that our processes have ossified so
much in the face of a huge amount of evidence that they need fixing.

Eliot

[Douglas Otis]

On Aug 13, 2006, at 4:41 AM, Eliot Lear wrote:

> However, I once again urge the IESG to recognize that RFC 2026
> needs fixing. We need to evolve as an organization. It does not
> bode well that our processes have ossified so much in the face of a
> huge amount of evidence that they need fixing.

While this may be a valid concern, document categorization has not
been attempted as an ongoing process, most likely because it
represents an effort best achieved by those using the information.
Moving documents to historic asked a simple question, does anyone
still use this document? This first required defining the document's
relationships with other documents by way of call-out or by formal
reference. The final grouping, or sets of RFCs were then
considered. The categorization of a small percentage of documents to
historic offers a modicum of guidance for ongoing endeavours, where
even this process was still highly speculative.

What should be clear is that there is greater value in being able to
view these documents in sets as they relate to stages of various
endeavours. A better goal would be to first organize the information
into a meaningful structure. This structure alone can easily
supplant any value that might be achieved by a categorization process
that requires more time and knowledge than available to a small group
attempting to administer the process. As the number and diversity of
endeavours increase, categorization becomes more difficult.

There are critical areas that must be watched closely and relate to
stability of the Internet itself. This might include careful
evaluation of experimental efforts or dealing with new security
issues. Once again, knowing a document's relationship with other
documents at various stages development would aid the focusing of
attention on these more pressing issues. The organization of the
information would also provide stable references, improve
coordination with other groups, or the discovery of the latest
information will be made easier when more complex subjects are
reviewed in literature. There was a lesson to be learned in the
decruft effort.

-Doug



.

[C. M. Heard]

On Sun, 13 Aug 2006, Eliot Lear wrote:
> [ ... ] I once again urge the IESG to recognize that RFC 2026
> needs fixing. We need to evolve as an organization. It does
> not bode well that our processes have ossified so much in the
> face of a huge amount of evidence that they need fixing.

Previously, Brian E Carpenter wrote:
> I [ ... ] do not believe there were any signs of newtrk reaching
> a consensus [on] what to do about those phenonema.

Despite some suggestions to the contrary, I would have to say that
I agree with Brian's assessment. Maybe one way forward would be
for the IESG to recharter newtrk with the specific mandate of
simply documenting what we actually practice.

//cmh

.

[Margaret Wasserman]

Hi John,

On Aug 10, 2006, at 11:18 PM, John C Klensin wrote:
> Hmm. Since the IESG has the option of doing it --indeed a
> requirement to do it which they have decided to not take
> seriously-- I'd say "yes"... independent of whether that decision
> is wise or not. The relevant gate is just semi-permanently closed.

The only time that we've ever done this, to my knowledge, the work
was completed by a design team and reviewed on the newtrk list. The
IESG merely had to approve the document that was produced by the
team. So, it is possible that the IESG could handle this
responsibility by the periodic (perhaps annual?) appointment of a
team to handle this for them.

I think it would be much more true to the description in RFC 2026,
though, if we had an automated process that added a list of PS
documents "for review" to the IESG agenda every two weeks, so that
these documents actually were reviewed by the IESG 24 months after
publication and every 12 months thereafter. IMO, in addition to
deprecating standards that are not implemented, the IESG should be
authorized to promote standards that are known to be widely
implemented, but that doesn't seem to be supported by RFC 2026.

The other alternative, if we don't think that this would be a useful
way for the IESG to spend their time, is to do an update to RFC 2026
to remove this requirement.

This points out one of the biggest flaws in our appeal process -- it
isn't really possible to appeal a non-action, so there is no official
way (short of a recall, which would seem awfully overblown in most
situations) for the community to insist that individual ADs or the
IESG as a whole do something that they haven't done or are not doing.

Margaret




.

[Brian E Carpenter]

The review is a no-op unless the people who care have produced
an implementation report. I think that's why there is basically
no reason to do anything except encourage implementation reports.
The workload is self-regulating.

Brian

Margaret Wasserman wrote:
>
>
> Hi John,
>
> On Aug 10, 2006, at 11:18 PM, John C Klensin wrote:
>
>> Hmm. Since the IESG has the option of doing it --indeed a
>> requirement to do it which they have decided to not take seriously--
>> I'd say "yes"... independent of whether that decision is wise or
>> not. The relevant gate is just semi-permanently closed.
>
>
> The only time that we've ever done this, to my knowledge, the work was
> completed by a design team and reviewed on the newtrk list. The IESG
> merely had to approve the document that was produced by the team. So,
> it is possible that the IESG could handle this responsibility by the
> periodic (perhaps annual?) appointment of a team to handle this for them.
>
> I think it would be much more true to the description in RFC 2026,
> though, if we had an automated process that added a list of PS
> documents "for review" to the IESG agenda every two weeks, so that
> these documents actually were reviewed by the IESG 24 months after
> publication and every 12 months thereafter. IMO, in addition to
> deprecating standards that are not implemented, the IESG should be
> authorized to promote standards that are known to be widely
> implemented, but that doesn't seem to be supported by RFC 2026.
>
> The other alternative, if we don't think that this would be a useful
> way for the IESG to spend their time, is to do an update to RFC 2026 to
> remove this requirement.
>
> This points out one of the biggest flaws in our appeal process -- it
> isn't really possible to appeal a non-action, so there is no official
> way (short of a recall, which would seem awfully overblown in most
> situations) for the community to insist that individual ADs or the IESG
> as a whole do something that they haven't done or are not doing.
>
> Margaret
>
>
>
>
> .
> newtrk resources:_____________________________________________________
> web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
> mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html
>
.

[Bill Fenner]

>I think it would be much more true to the description in RFC 2026,
>though, if we had an automated process that added a list of PS
>documents "for review" to the IESG agenda every two weeks, so that
>these documents actually were reviewed by the IESG 24 months after
>publication and every 12 months thereafter.

An automated process to get this info has existed forever (*), but may be so
underpublicized that I'm the only person (including the rest of the IESG)
that knows about it: http://www.ietf.org/iesg/1old_standards.txt

There's a bit of a startup problem with the proposal of having them
automatically on the IESG agenda - there are 61 Draft Standards and
696 Proposed Standards on the list.

Bill

(*) - web.archive.org sees a version from 2001; my recollection is that
it existed before that
.

[Margaret Wasserman]

> There's a bit of a startup problem with the proposal of having them
> automatically on the IESG agenda - there are 61 Draft Standards and
> 696 Proposed Standards on the list.

Still? I thought that the whole point of the "cruft" exercise was to
clear out the backlog, so that we would be able to start fresh... On
second thought, I doubt there is any way for you tool to tell which
documents were intentionally retained by the "cruft" exercise and
don't have to be reviewed again for several months.

Of course with 750 PS and DS documents in circulation and ~25
telechats per year, we're talking about having the IESG review the
status of an average of 30 documents per telechat, which might be
fairly daunting even after we hit steady state.

Margaret
.

[Brian E Carpenter]

Margaret Wasserman wrote:
>> There's a bit of a startup problem with the proposal of having them
>> automatically on the IESG agenda - there are 61 Draft Standards and
>> 696 Proposed Standards on the list.
>
>
> Still? I thought that the whole point of the "cruft" exercise was to
> clear out the backlog, so that we would be able to start fresh... On
> second thought, I doubt there is any way for you tool to tell which
> documents were intentionally retained by the "cruft" exercise and don't
> have to be reviewed again for several months.
>
> Of course with 750 PS and DS documents in circulation and ~25 telechats
> per year, we're talking about having the IESG review the status of an
> average of 30 documents per telechat, which might be fairly daunting
> even after we hit steady state.

And pointless. The only ones that should ever get on an agenda are
ones supported by an implementation report (for DS), a deployment
report (for STD) or a disuse report (for Historic).

Brian
.

[Margaret Wasserman]

On Aug 11, 2006, at 11:00 AM, Brian E Carpenter wrote:

>> Of course with 750 PS and DS documents in circulation and ~25
>> telechats per year, we're talking about having the IESG review
>> the status of an average of 30 documents per telechat, which
>> might be fairly daunting even after we hit steady state.
>
> And pointless. The only ones that should ever get on an agenda are
> ones supported by an implementation report (for DS), a deployment
> report (for STD) or a disuse report (for Historic).

I agree. Personally, I would favor a short update to RFC 2026 to
remove this responsibility from the IESG. In the meantime, I am not
personally bothered by the fact that the IESG is ignoring this
responsibility.

Margaret

.

[Eliot Lear]

I don't want the IESG to do such a costly review either. I agree it is
pointless. But let us also recognize that it should be a nail in the
coffin of a three stage standards process, and it should also seriously
bring into question the viability of a two stage process. But I'll try
anything once.

Eliot
.

[Douglas Otis]

On Aug 11, 2006, at 8:27 AM, Margaret Wasserman wrote:

>
> On Aug 11, 2006, at 11:00 AM, Brian E Carpenter wrote:
>
>>> Of course with 750 PS and DS documents in circulation and ~25
>>> telechats per year, we're talking about having the IESG review
>>> the status of an average of 30 documents per telechat, which
>>> might be fairly daunting even after we hit steady state.
>>
>> And pointless. The only ones that should ever get on an agenda are
>> ones supported by an implementation report (for DS), a deployment
>> report (for STD) or a disuse report (for Historic).
>
> I agree. Personally, I would favor a short update to RFC 2026 to
> remove this responsibility from the IESG. In the meantime, I am
> not personally bothered by the fact that the IESG is ignoring this
> responsibility.

Would that be declaring victory, or admitting defeat? John made a
fairly good point. Repeated failures in addressing an issue only
makes the system appear less functional. Declaring victory sounds
more like "Stay the course."

An overlay name.serial_number reference mechanism for tracking a
progression of RFCs in coherent sets will offer useful information.
This reference mechanism should actually reduce administrative
burdens as well. As Brian suggested, such a reference mechanism does
not require procedural change to existing processes.

The application of RFC related information is often focused upon what
is "current" for development, and what is "stable" for production.
While the IESG may be in a good position to declare currently
accepted documents, a dependency upon vendors is required to
determine the set offering "stable" interchange. To be more
productive and to introduce fewer conflicts, provide an easier means
for these vendors to succinctly describe the set of RFCs used in
their releases. A release may indicate that it is based upon foo.37
and bar.5. Perhaps foo.40 and bar.6 is currently published.

Once a reference scheme is instantiated and it offers meaningful
utility, supplanting the RFC category process may become the logical
next step. Currently, this path appears to be unclear.

-Doug


.

[John Leslie]

Brian E Carpenter <***@zurich.ibm.com> wrote:
> Margaret Wasserman wrote:
>>
>> Of course with 750 PS and DS documents in circulation and ~25 telechats
>> per year, we're talking about having the IESG review the status of an
>> average of 30 documents per telechat, which might be fairly daunting
>> even after we hit steady state.
>
> And pointless. The only ones that should ever get on an agenda are
> ones supported by an implementation report (for DS), a deployment
> report (for STD) or a disuse report (for Historic).

Might I suggest an ION stating an IESG procedure that in the absence
of an implementation, deployment, or disuse report every PS or DS due
for IESG review shall be placed on a single agenda item to maintain
them at the same maturity level for the following 12 months?

--
John Leslie <***@jlc.net>
.

[Brian E Carpenter]

Replying to three messages in one...

John Leslie wrote:
...
> Might I suggest an ION stating an IESG procedure that in the absence of an implementation, deployment, or disuse report every
> PS or DS due for IESG review shall be placed on a single agenda item to maintain them at the same maturity level for the
> following 12 months?

I'm more motivated to actively encourage the community to post
implementation, deployment, or disuse reports as a matter of course.
I think if we could get that into our DNA, the rest would flow
as a matter of course.

John C Klensin wrote:
> It has become clear to me during the last several days of discussion that we don't have a clear idea / consensus about what
> "gating" means. And a critical path analysis might point the finger at places other than the IESG, while this "gating"
> discussion starts with the IESG as the answer and works (IMO) backwards.

I think that is true, and I ask John Leslie to take account of it.

C. M. Heard wrote:
...
> Previously, Brian E Carpenter wrote:
>
>>> I [ ... ] do not believe there were any signs of newtrk reaching
>>> a consensus [on] what to do about those phenonema.
>
>
> Despite some suggestions to the contrary, I would have to say that
> I agree with Brian's assessment. Maybe one way forward would be
> for the IESG to recharter newtrk with the specific mandate of
> simply documenting what we actually practice.

Well, my latest update to draft-carpenter-rfc2026-critique was made
in that spirit. From that exercise, I'm not convinced a WG effort
is really needed for this, but I agree it's worth finishing :-)

Brian
.

[John C Klensin]

--On Thursday, 10 August, 2006 12:38 +0200 Eliot Lear
<***@cisco.com> wrote:

> In the process of doing so, we should recognize that the three
> step process is obsolete. Anyone who disgrees with that
> statement is ignoring the evidence. Our tradition as an
> organization is to attempt to rectify our specifications based
> on running code. Let us please do so in this instance.

Eliot,

I don't know whether it is worth prolonging this discussion, but
suggest there is a counter-hypothesis --or a least a positive
feedback cycle-- that could explain "the evidence" other than
"the three step process is obsolete". With the understanding
that I'm no longer convinced that we need more than two steps
--at least without a drastic change in the Draft-> Full model--
the intent about Proposed was that the approval process be
fairly lightweight in all cases that didn't appear to pose a
serious danger to the Internet. The threshold for Proposed has
grown higher and higher, with more and more nit-picking and
hoop-jumping to get a document through the system. Under the
counter-hypothesis, this has driven the incentives to move
beyond Proposed down because of some or all of

(i) It is so exhausting to get something to Proposed
that there is no energy left.

(ii) It takes so long to get to Proposed that product
cycles dictate implementing and deploying there and then
stopping.

(iii) Documents are required to be so "finished" to get
to Proposed that there is little point putting effort
into trying to make an improved form.

And so on.

If any or all of those are a significant part of the problem,
then the fix may lie in lowering the effective barriers to
Proposed for lots of cases, not in major changes to the
Standards track. And that fix does not require changes to 2026,
indeed, it is completely consistent with it.

john

.

[Brian E Carpenter]

There's been some good discussion but nothing that changes my
opinion that closing this WG is the right thing to do, for
the reasons I gave, above all the lack of a broad consensus
for any specific major change.

The discussion can certainly continue, and I will ask for this
list to be retained if possible, at least for a while.

I would like to thank Scott Bradner for his willingness to
chair this WG, even when things got tricky or frustrating.
Also thanks go to everyone who contributed drafts or ideas.

Brian Carpenter
General Area Director
.

[Scott Bradner]

Margaret sed:
> This points out one of the biggest flaws in our appeal process -- it
> isn't really possible to appeal a non-action

its been done (Dave Crocker)

a non-action is a type of action (I guess)

but it would be a rather big waste of everyone's time and would not
change how the Internet runs

Scott
.

[Scott Bradner]

Brian asserted:
> The review is a no-op unless the people who care have produced
> an implementation report.

not quite - the review could result an effort to reclassify the
RFC as historic (no implementation report needed for unused technology :-) )

Scott
.

[Margaret Wasserman]

Just for the record. I am completely unconvinced that doing this
review is actually useful...

Even if we move documents to historic, that doesn't remove their code-
point assignments or stop people from using them.

My hope would be that if we push on the IESG to actually follow these
rules, that will give us at least one group of 15 people with some
motivation to change RFC 2026 to reflect what we've been doing for
the past ~10 years. I think that most of the IETF is unaware of this
requirement in RFC 2026 and doesn't care one way or the other whether
the IESG periodically reviews our PS documents.

I don't actually think that we need a WG to consider whether a change
is needed to fix this, though. So, this isn't an argument against
shutting down newtrk.

Margaret


.

[Brian E Carpenter]

Scott Bradner wrote:
> Brian asserted:
>
>>The review is a no-op unless the people who care have produced
>>an implementation report.
>
>
> not quite - the review could result an effort to reclassify the
> RFC as historic (no implementation report needed for unused technology :-) )

I guess. But as the decruft exercise showed, this isn't entirely a no-op
either; actually both the Last Call and the IESG review identified a few
more RFCs asserted still to be in use.

However, there is nothing intrinsic to the IESG that makes it good
at doing either decruft reviews or promotion reviews. If people in
the community bring well formulated decruft or promotion proposals
to the IESG, there's no reason they won't get handled.

Brian
.

[Scott Bradner]

Brian notes:
> However, there is nothing intrinsic to the IESG that makes it good
> at doing either decruft reviews or promotion reviews.

some people might claim the reverse :-)

Scott
.

[Robert Snively]

Still got the problems.

Haven't got the solutions.

What other forum would you suggest to approach the
problems?

Bob

-----Original Message-----
From: owner-***@lists.uoregon.edu
[mailto:owner-***@lists.uoregon.edu] On Behalf Of Brian E Carpenter
Sent: Tuesday, August 15, 2006 6:01 AM
To: New Track
Subject: Re: [newtrk] IETF Process discussions - next steps

There's been some good discussion but nothing that changes my
opinion that closing this WG is the right thing to do, for
the reasons I gave, above all the lack of a broad consensus
for any specific major change.

The discussion can certainly continue, and I will ask for this
list to be retained if possible, at least for a while.

I would like to thank Scott Bradner for his willingness to
chair this WG, even when things got tricky or frustrating.
Also thanks go to everyone who contributed drafts or ideas.

Brian Carpenter
General Area Director
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html


.

[Douglas Otis]

On Aug 15, 2006, at 9:03 AM, Robert Snively wrote:

> Still got the problems.
>
> Haven't got the solutions.
>
> What other forum would you suggest to approach the problems?

Perhaps a new WG could be chartered to structure RFC related
information. To avoid affecting any existing process, this
structuring would not include any normative language related to any
existing RFC. However a process for simple review and acceptance of
structuring elements should be considered. Instead of this effort
increasing administrative burdens, this should result in a net
reduction once instantiated. The instantiation of the structure
could be either incremental or complete depending upon the
participation within the WG. In addition to added structure making
access to the information more user friendly, the structuring should
have benefits related to coordinating with other SDOs and other
literature.

Once there is experience in how the structure is used, then review
the categorization process. The categorization may then need to be
raised to higher level structure elements.

-Doug

.

[Brian E Carpenter]

Right now it seems that the community doesn't want to invest
effort in solving the problem.

As far as the structure of the RFC indexes are concerned,
that's an operational matter that I believe is best arranged directly
with the RFC Editor as part of the future contract (you will recall
that the RFP for that contract has been issued).

Brian

Douglas Otis wrote:
>
> On Aug 15, 2006, at 9:03 AM, Robert Snively wrote:
>
>> Still got the problems.
>>
>> Haven't got the solutions.
>>
>> What other forum would you suggest to approach the problems?
>
>
> Perhaps a new WG could be chartered to structure RFC related
> information. To avoid affecting any existing process, this structuring
> would not include any normative language related to any existing RFC.
> However a process for simple review and acceptance of structuring
> elements should be considered. Instead of this effort increasing
> administrative burdens, this should result in a net reduction once
> instantiated. The instantiation of the structure could be either
> incremental or complete depending upon the participation within the
> WG. In addition to added structure making access to the information
> more user friendly, the structuring should have benefits related to
> coordinating with other SDOs and other literature.
>
> Once there is experience in how the structure is used, then review the
> categorization process. The categorization may then need to be raised
> to higher level structure elements.
>
> -Doug
>
> .
> newtrk resources:_____________________________________________________
> web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
> mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html
>
.

[Douglas Otis]

On Aug 16, 2006, at 1:54 AM, Brian E Carpenter wrote:

> Right now it seems that the community doesn't want to invest effort
> in solving the problem.

A small group can not be cognizant of how 700 documents are being
used in the field years afterwards. Although ISDs offered a
solution, the administrative attention needed for reviewing an
aggregation of modified dated material is still likely best placed on
material related to current issues. However ISDs, by providing a
stable reference, offered significant value.

> As far as the structure of the RFC indexes are concerned, that's an
> operational matter that I believe is best arranged directly with
> the RFC Editor as part of the future contract (you will recall that
> the RFP for that contract has been issued).

More than just a set of indexes is needed. Composing a structure
retaining the ISD reference feature will likely produce a greater
impact on a set of document's stature than would RFC2026 categories.
While this effort could become a task for the RFC editor, it seems
defining a suitable structure would be something of general
interest. The goal would be to ensure a relational structure is
created by interested parties in the earliest stages of a document's
development; a cradle to grave method for tracking endeavours, rather
than just individual documents.

Is there an RFC Editor related forum?

-Doug
.

[John C Klensin]

For whatever it is worth, I think I am in almost complete
agreement with Doug about the comments below. But I still do
not believe that, right now, the community is convinced enough
that this is a problem to put more energy into solving it,
especially in the light of probable IESG resistance.

john


--On Wednesday, 16 August, 2006 12:26 -0700 Douglas Otis
<***@mail-abuse.org> wrote:

>
> On Aug 16, 2006, at 1:54 AM, Brian E Carpenter wrote:
>
>> Right now it seems that the community doesn't want to invest
>> effort in solving the problem.
>
> A small group can not be cognizant of how 700 documents are
> being used in the field years afterwards. Although ISDs
> offered a solution, the administrative attention needed for
> reviewing an aggregation of modified dated material is still
> likely best placed on material related to current issues.
> However ISDs, by providing a stable reference, offered
> significant value.
>
>> As far as the structure of the RFC indexes are concerned,
>> that's an operational matter that I believe is best
>> arranged directly with the RFC Editor as part of the future
>> contract (you will recall that the RFP for that contract
>> has been issued).
>
> More than just a set of indexes is needed. Composing a
> structure retaining the ISD reference feature will likely
> produce a greater impact on a set of document's stature than
> would RFC2026 categories. While this effort could become a
> task for the RFC editor, it seems defining a suitable
> structure would be something of general interest. The goal
> would be to ensure a relational structure is created by
> interested parties in the earliest stages of a document's
> development; a cradle to grave method for tracking endeavours,
> rather than just individual documents.
>
> Is there an RFC Editor related forum?
>
> -Doug
> .
> newtrk
> resources:_____________________________________________________
> web user interface:
> http://darkwing.uoregon.edu/~llynch/newtrk.html
> mhonarc archive:
> http://darkwing.uoregon.edu/~llynch/newtrk/index.html




.

[Brian E Carpenter]

Personally, I believe the best thing that could happen is
for somebody, or a few somebodys, to produce a web page that
does what http://www.rfc-editor.org/rfcxx00.html does
but better*. With that in front of us, it would be much easier
to have a discussion.

* i.e. with the standards track material organized into
"obsoletes" and "updates" threads, with the latest versions
first.

Brian


John C Klensin wrote:
> For whatever it is worth, I think I am in almost complete
> agreement with Doug about the comments below. But I still do
> not believe that, right now, the community is convinced enough
> that this is a problem to put more energy into solving it,
> especially in the light of probable IESG resistance.
>
> john
>
>
> --On Wednesday, 16 August, 2006 12:26 -0700 Douglas Otis
> <***@mail-abuse.org> wrote:
>
>
>>On Aug 16, 2006, at 1:54 AM, Brian E Carpenter wrote:
>>
>>
>>>Right now it seems that the community doesn't want to invest
>>>effort in solving the problem.
>>
>>A small group can not be cognizant of how 700 documents are
>>being used in the field years afterwards. Although ISDs
>>offered a solution, the administrative attention needed for
>>reviewing an aggregation of modified dated material is still
>>likely best placed on material related to current issues.
>>However ISDs, by providing a stable reference, offered
>>significant value.
>>
>>
>>>As far as the structure of the RFC indexes are concerned,
>>>that's an operational matter that I believe is best
>>>arranged directly with the RFC Editor as part of the future
>>>contract (you will recall that the RFP for that contract
>>>has been issued).
>>
>>More than just a set of indexes is needed. Composing a
>>structure retaining the ISD reference feature will likely
>>produce a greater impact on a set of document's stature than
>>would RFC2026 categories. While this effort could become a
>>task for the RFC editor, it seems defining a suitable
>>structure would be something of general interest. The goal
>>would be to ensure a relational structure is created by
>>interested parties in the earliest stages of a document's
>>development; a cradle to grave method for tracking endeavours,
>>rather than just individual documents.
>>
>>Is there an RFC Editor related forum?
>>
>>-Doug
>>.
>>newtrk
>>resources:_____________________________________________________
>>web user interface:
>>http://darkwing.uoregon.edu/~llynch/newtrk.html
>>mhonarc archive:
>>http://darkwing.uoregon.edu/~llynch/newtrk/index.html
>
>
>
>
>
> .
> newtrk resources:_____________________________________________________
> web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
> mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html
>
.

[Robert Snively]

This is a hard question. I still believe that the
fundamental problem is the standardization track
is flawed and that IETF culture does not allow serious
consideration of various simplifications and delegation
procedures that could improve the standardization
track.

A second, and perhaps equally important problem, is
the underlying premise that the internet must be
properly protected and back compatibility preserved.
Many of the standards are peripheral to the internet
or reflect new types of traffic, but are still processed
through the same intellectual filters as are those
standards that directly impact internet structure.
If there were a way to isolate certain standards for
more thorough review, allowing others to go forward
on a streamlined process, I believe that might help.

I believe the will is there, but that we have over constrained
the possible solutions.

Bob

-----Original Message-----
From: Brian E Carpenter [mailto:***@zurich.ibm.com]
Sent: Wednesday, August 16, 2006 1:54 AM
To: Douglas Otis
Cc: Robert Snively; New Track
Subject: Re: [newtrk] IETF Process discussions - next steps

Right now it seems that the community doesn't want to invest
effort in solving the problem.

As far as the structure of the RFC indexes are concerned,
that's an operational matter that I believe is best arranged directly
with the RFC Editor as part of the future contract (you will recall
that the RFP for that contract has been issued).

Brian

Douglas Otis wrote:
>
> On Aug 15, 2006, at 9:03 AM, Robert Snively wrote:
>
>> Still got the problems.
>>
>> Haven't got the solutions.
>>
>> What other forum would you suggest to approach the problems?
>
>
> Perhaps a new WG could be chartered to structure RFC related
> information. To avoid affecting any existing process, this
structuring
> would not include any normative language related to any existing RFC.

> However a process for simple review and acceptance of structuring
> elements should be considered. Instead of this effort increasing
> administrative burdens, this should result in a net reduction once
> instantiated. The instantiation of the structure could be either
> incremental or complete depending upon the participation within the
> WG. In addition to added structure making access to the information
> more user friendly, the structuring should have benefits related to
> coordinating with other SDOs and other literature.
>
> Once there is experience in how the structure is used, then review
the
> categorization process. The categorization may then need to be
raised
> to higher level structure elements.
>
> -Doug
>
> .
> newtrk resources:_____________________________________________________
> web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
> mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html
>


.