Subject: [Fwd: IETF Process discussions - next steps]

From: Brian E Carpenter <[email-masked]>
Date: Fri, 25 Aug 2006 13:17:22 +0200

I was quite surprised to discover that this message is not
in the mailing list archive, so I am repeating it.
A copy certainly reached the newtrk WG prior to
its closure.

-------- Original Message --------
Subject: IETF Process discussions - next steps
Date: Thu, 10 Aug 2006 11:41:47 +0200
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: IETF discussion list <[email-masked]>

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

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Andy Bierman <[email-masked]>
Date: Fri, 25 Aug 2006 20:45:12 -0700

> (draft-carpenter-newtrk-questions-00.txt)

IMO, there are IETF-wide and area-wide standards-track
advancement issues are varying importance.

I think each AD should at least consider (and hopefully write down)
what the "advancement policy" is for their area.

For example, we have learned through experience that advancement
of MIB modules is quite problematic, even though it is very straight-forward
to define and evaluate the interoperability requirements.

Vendors have been rather reluctant to respond to implementation surveys.
(This isn't that surprising, since SW engineers usually have to fill
out the surveys, and we hate to write documentation :-)
Even when this seemingly harmless survey is returned, many respondents
say they don't believe this effort is of any value.

So the reports are inaccurate and difficult to obtain.  Worse yet,
decisions to keep or deprecate MIB objects are based on these reports.
In the Entity MIB WG, we actually found our efforts to deprecate
some MIB objects (per SOP) during advancement to be harmful to
interoperability.

I believe we now have an unofficial "don't ask, don't advance" policy.
That is, the WG Chairs won't attempt to advance RFCs containing MIB modules
beyond Proposed Standard anymore, and the ADs won't ask them to do so.

Yet, I believe there is some value for operators to know the
difference between a mature MIB module like RMON-MIB and the
first version of a MIB module like RAQMON-MIB.
The SMI sort of provides that info, but not very clearly to non-experts.

Andy