Subject: [newtrk] pepost - IESG comments on ISDs

From: [email-masked] (Scott Bradner)
Date: Mon, 6 Jun 2005 10:08:20 -0400 (EDT)

just so that its easier to find - here is a repost of the IESG comments
on the ISD proposal - please do not respond to this as a whole - I'll
send a series of targeted messages on parts of it

------

sent by Brian E Carpenter Tue, 10 May 2005 09:51:44 +0200

------
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

---

From: mcr <[email-masked]>
Date: Mon, 06 Jun 2005 12:33:33 -0400

-----BEGIN PGP SIGNED MESSAGE-----

{I'm reading emails definitely out of order, btw}

>>>>> "Scott" == Scott Bradner <[email-masked]> summarizes:
    Scott> Rather than
    Scott> clarifying and simplifying the "standards action" event, it
    Scott> would get more complex.

  As a supporter of ISD as a replacement for the 3-level process, I want
to say that I agree with this statement. It is correct, but misses the point.

  But, the reason that ISD appears to make it more complex is because it
is doing more than we currently do. 

  Sure, in *THEORY*, ISD isn't introducing much that is new, but in
practice, it permits us to more easily do more. Or to put it
graphically:

  effort
    |            THEORY
    |
    |               ISD
    |
    |   PRAC
    |  
    |
    +------------------------ outcome

    PRAC   == what happens now.	(RFC/PS)
    THEORY == what 2026,etc. say we are supposed to do. (STD)
    ISD	   == what ISD proposals

  So, yes, it will take more effort, but we'll get more return for that
investment. 

    Scott> The second approach would be to create some sort of document
    Scott> series for roadmap documents.  The ISDs would focus on
    Scott> describing the documents that compose a standard and their
    Scott> interrelations.  These ISDs would be fairly complicated to
    Scott> write--at least as complicated as existing roadmap documents.
 
  Roadmaps tend to be written when the spec is first published.
  ISDs would be written and updated some time after publication.

- -- 
] Michael Richardson          Xelerance Corporation, Ottawa, ON |  firewalls  [
] mcr @ xelerance.com           Now doing IPsec training, see   |net architect[
] http://www.sandelman.ca/mcr/    www.xelerance.com/training/   |device driver[
]                    I'm a dad: http://www.sandelman.ca/lrmr/                 [
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html