The IESG discussed the ISD proposal at some length during its recent
retreat meeting.

The short summary is that the IESG understands several problems
that the ISD proposal seems to be trying to solve but believes
the proposal is not sufficiently clear about what problem is being
solved and has issues with the proposed solution. However, to be
constructive, the IESG wants to discuss possible ways forward to
achieve some or all of the desired results. Assuming newtrk meets
in Paris, IESG members will make a best effort to be present,
and we assume there will be email discussion before then.

Although we know the authors will disagree, several members expressed
significant concerns that this proposal would increase the complexity
of the standards process, would slow down the IETF's throughput and
would not in the end be useful to implementers.

Specifically, concern was expressed that determining the right
granularity (e.g. how many ISDs would be needed to cover the SIP area,
and how many SIP RFCs would be pointed to by multiple ISDs) would be
very hard, and would lead to complexity and confusion when updates occur.
Rather than clarifying and simplifying the "standards action" event,
it would get more complex.

Another concern that was expressed was that, except for trivial cases
where an ISD is probably not needed anyway, experience (e.g. RFC 1812,
draft-ietf-ipv6-node-requirements-11.txt) suggests that ISDs are likely to
require major effort to produce. That effort is probably justified in
some cases (as the cited examples show) but not for every single standards
action.

There was a general observation that what the IETF does well is write
specifications, and maybe we should leave it at that, with the "market"
choosing which to turn into de facto standards.

Thus we are not sure if it is worthwhile to spend the necessary effort
to turn the current ISD proposal into something that would in practice
improve the standards process.  If we choose to spend more effort on the
ISD proposal in its present form, we should recognize that this will be a
high-risk, high-cost approach and we may ultimately fail to produce
something that works for the IETF community better than what we do today.

However, there was a feeling that for complex or fundamental
technologies (e.g. TCP, SMTP, SIP, IPSEC) there would be a clear benefit
to the community to have documents of some kind that give appropriate
guidance to implementers and operators.

There are two directions we could take if we want to continue work on
ISDs.  The IESG believes it is important to pick one of these
directions.  There is internal disagreement within the IESG about which
direction we should take.  Some IESG members expressed objections to
each approach; more discussion is needed to confirm that if an
approach is taken the IESG can live with that approach. We'd like
to have that dialog with newtrk.

The first approach is to treat the ISDs as a light-weight replacement
for the three-level standards track.  The goal would be to make ISDs
very simple; minimize text in the document and make an ISD little more
than a collection of links and metadata. This would, in effect, give
IETF blessing to the realities that the Internet runs mainly on
Proposed Standards and that the STD series has failed as a
citation series.

The second approach would be to create some sort of document series
for roadmap documents.  The ISDs would focus on describing the
documents that compose a standard and their interrelations.  These ISDs
would be fairly complicated to write--at least as complicated as
existing roadmap documents.  We do not believe that if ISDs are going
to be roadmaps their approval should be linked to standards-action
document approval. Also, we do not believe that if ISDs are roadmaps
they should be required for all technologies; instead they should be used when
appropriate. (This is orthogonal to the three-level standards track;
that could be simplified independently, as implied by the newtrk charter.)

We do not believe ISDs can fill both possible roles.  We believe the
current specification does not clearly state a goal and we believe
that the lack of goal introduces significant ambiguity into the
proposal.

Regardless of what approach is taken, we need to consider the
procedural implications of these changes.  We believe that significant
effort needs to be put into thinking about how these changes will be
automated. The only way to constantly improve the IETF's document
throughput is to maximize automatic tools. Before any ISD proposal
can be implemented, we need to understand how it would be implemented,
how it would modify the existing automation tools, who would implement it
and what the costs would be.  This effort needs to be closely coordinated
with the ISD proposal: while these details may not be appropriate to
include in the ISD document we need to confirm implementation is
possible while we can still make changes to the proposal.

     Brian
     for the IESG





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