Subject: [newtrk] IESG comments on ISD proposal

From: Brian E Carpenter <[email-masked]>
Date: 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: Pekka Savola <[email-masked]>
Date: Tue, 10 May 2005 13:29:39 +0300 (EEST)

> some cases (as the cited examples show) but not for every single standards

FWIW, I agree with both concerns.

> guidance to implementers and operators.

Agreed.  Add "DNS" to the mix.  From my perspective, it's a protocol 
mess which most requires a roadmap or a "minimal implementation 
requirements" document; there's just too many documents out there to 
understand, and just too many things an imlementer can do wrong.

However, I'm aware only of one WG which has been chartered to produce 
such documents.  So the question is, doesn't the IESG see the need for 
roadmaps (or similar documents) as the WGs aren't chartered to produce 
them ?

> Proposed Standards and that the STD series has failed as a

This could work.  I guess the benefit of this approach would be to 
document specification problems (which are too extensive for 
RFC-editor errata) and solutions, without having to (immediately) 
crank up a heavier process for revising the spec?

However, while revising the ISD might be a bit simpler, I guess it 
would require at least some form of IESG approval, so we'd mainly 
optimize away the RFC-editor publication and keep the modifications 
(the text the IESG needs to read) small.

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

Agree.

> that the lack of goal introduces significant ambiguity into the

Agree.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: Bruce Lilly <[email-masked]>
Date: Tue, 10 May 2005 09:58:54 -0400

> Proposed Standards and that the STD series has failed as a

I'm growing weary of hearing that claim, which I've not seen substantiated.
I'll stop short of calling "bullshit" and simply say that I don't believe
it.  The Internet runs mainly on full Standards, as I see it: IP (STD 5),
UDP (STD 6) and TCP (STD 7), Telnet (STD 8), FTP (STD 9), SMTP (STD 10),
the Internet Message Format (STD 11), DNS (STD 13), MIBs (STD 17) and
SNMP (STD 62), PPP (STD 51), POP (STD 53), etc.   In addition, there are
some Draft Standards which are widely used: NTP (RFC 1305, March 1992),
HTTP (RFC 2616, June 1999), and MIME (RFCs 2045-2049, November 1996). I
will grant that IMAP (RFC 3501, March 2003) is a Proposed Standard that
is widely used. [I have included dates for a reason]  Where precisely are
the supposed PSs that have supplanted IP, TCP, and UDP on the Internet?

> that could be simplified independently, as implied by the newtrk charter.)

Sounds reasonable -- but who will maintain the roadmap documents?  If
"the IESG", then it seems that updates -- if not approval per se --
should be linked to IESG actions.  Roadmap documents would almost certainly
be of benefit to implementers -- many protocols are extensible, and many
have been extended; it's certainly challenging to keep track of all of the
relevant extensions.
 
> that the lack of goal introduces significant ambiguity into the

Before deciding on a goal -- indeed before deciding that there are only
two possible specific approaches -- it may be instructive to ask what the
real core problems are.  For example, let's consider MIME, stuck at DS
for nearly a decade.  RFC 2026 section 6.2 requires IESG review after 24
months and at subsequent 12 month intervals.  What specific actions did
the IESG take in November 1998, 1999, 2000, 2001, 2002, 2003, and 2004 to
progress MIME?  If no actions were taken, why not?  If action was taken,
why has it been ineffective?  Or consider SIP (PS since June 2002); what
action was taken in June 2004, and what action is planned for June 2005?
By examining such cases, perhaps some specific root causes can be identified,
and having identified specific problems, appropriate solutions can be
found.

Either abandoning the Standards Track which has produced IP, UDP, TCP,
SMTP, FTP, Telnet, POP, etc., or creating yet another set of documents
that need to be maintained -- without first identifying and documenting
specific problem(s) that either action would remedy without introducing
more serious problems -- might prove fruitless at best, or harmful.
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: Sam Hartman <[email-masked]>
Date: Tue, 10 May 2005 10:10:23 -0400

>>>>> "Pekka" == Pekka Savola <[email-masked]> writes:

    Pekka> to produce such documents.  So the question is, doesn't the
    Pekka> IESG see the need for roadmaps (or similar documents) as
    Pekka> the WGs aren't chartered to produce them ?

I certainly don't think the IESG has time to write these documents
ourselves.  I think that the reason that these aren't typically
chartered is lack of available effort.  

If you can find people with the time to work on some particular
technology roadmap, by all means propose a BOF or charter modification
to existing working group.

Whether such documents are ISDs or RFCs is mostly orthogonal to how
much effort is required.  If we have people to do the work it can
happen.  Otherwise it will not.

--Sam

.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 10 May 2005 10:31:46 -0700

> Proposed Standards and that the STD series has failed as a

Keep the ISDs effectively as simple meta-glue to guide developers in
understanding currently related documents.  This service would be most
welcome.  Creating automated links to errata and contemporaneous
overviews of these related documents would ensure important information
not escape notice.  The meta-glue should not require an author, nor
alter content of any RFC.

The referenced overview can be a separate process, facilitated by a
meta-glue approach.  Rather than developing a two-tier standards
process, all authoritative information should remain within the RFC.
The overviews, as created and updated, would comment on implementation
experience only.  If there is a desire to alter an RFC, write an RFC.
Such a rule would preserve process clarity.

Unlike the RFC, an overview would be more of a living document, with a
similar nature to that of errata, which notes corrections as discovered.
An overview would document which RFCs and related options are presently
used, and therefore add value to the RFC. These overviews could
effectively play the role of declaring status, but in a less formal
manner.  Having this ISD meta-glue kept a separate effort from errata or
an ongoing overview process, should ensure prompt deployment, while
still offering significant value.

-Doug

.

---

From: Pekka Savola <[email-masked]>
Date: Tue, 10 May 2005 22:06:16 +0300 (EEST)

> happen.  Otherwise it will not.

My point is: if the IESG thought roadmap documents were important, 
such docs would be much more commonplace in the WG charters.

It's of course possible to work on this by collecting sufficient 
number of like-minded individuals, but I doubt such an attempt would 
be all that successful.

The IESG needs to see this as a very important thing, otherwise it 
won't really happen.

---

From: Sam Hartman <[email-masked]>
Date: Tue, 10 May 2005 15:32:45 -0400

>>>>> "Pekka" == Pekka Savola <[email-masked]> writes:

    Pekka> My point is: if the IESG thought roadmap documents were
    Pekka> important, such docs would be much more commonplace in the
    Pekka> WG charters.

That's not how it works.  If we don't believe that people will do the
work we tend not to charter it.

So you'd see it in charter if the IESG believed there was interest in
a particular case or if the IESG believed it was so important in a
particular case that the general work should not proceed without it.

.

---

From: Pekka Savola <[email-masked]>
Date: Tue, 10 May 2005 22:49:41 +0300 (EEST)

> work we tend not to charter it.

Lots of people seem to be disinterested in working on problem 
statements, requirements documents, framework documents, or whatnot, 
yet somehow those often end up in the charters of a lot of WGs.

Apply the same techniques, if the IESG feels writing roadmap documents 
is useful.  If the IESG doesn't, at least the roadmap version of the 
ISD is out.

---

From: [email-masked] (Scott Bradner)
Date: Tue, 10 May 2005 20:24:59 -0400 (EDT)

> The IESG needs to see this as a very important thing, otherwise it 

just so, and it appears that they do not

Scott
.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 11 May 2005 11:41:36 +0200

> just so, and it appears that they do not

What makes you think that? The fact that the IESG spent much more
agenda time than planned on this at our retreat, the fact that
we prepared a quite lengthy response to the WG, or the fact that
we expressed a desire to engage in constructive discussion by email
and in Paris?

    Brian

.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 11 May 2005 11:43:33 +0200

Pekka Savola wrote:
> statements, requirements documents, framework documents, or whatnot, yet 
> somehow those often end up in the charters of a lot of WGs.
> 
> is useful.  If the IESG doesn't, at least the roadmap version of the ISD 
> is out.

You're going too fast. As our note said, we didn't have consensus on this,
and that's why we have engaged in discussion with the WG.

   Brian

.