Re: [newtrk] IESG comments on ISD proposal

[Bruce Lilly <[e-mail]>]

On Tue May 10 2005 03:51, Brian E Carpenter wrote:

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

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?

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

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

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