Subject: Re: What's been done [Re: Voting (again)]

From: John C Klensin <[email-masked]>
Date: Thu, 28 Apr 2005 20:11:23 -0400

--On Wednesday, 27 April, 2005 08:41 -0700 Dave Crocker
<[email-masked]> wrote:

>>  Proposals for upgrading/streamlining standards track in
>>  discussion (i.e. newtrk and specifically the ISD proposal,
>>  but there's certainly more to do in newtrk)
> 
> Another derailed activity.  Another activity that has nothing
> to do with  quality, timeliness or relevance.
> 
> Go ahead, explain how it does.  

Dave,

Here we disagree, or I most assuredly would not be spending time
on it.  I believe that, properly implemented and used, the ISD
work could result in much faster track processes for corrections
and minor alterations to standards-track materials.  By avoiding
the need to create new RFCs and perhaps lowering the frequency
with which we need to spin up WGs to deal with issues on which
consensus is already fairly clear, we should be able to improve
quality and timeliness and, in the process, free up cycles to
invest in quality and timeliness in other areas.

> Explain how current document labeling practises hurt the
> IETF's utility to the  Internet community.

I am far less convinced of it than the above, but I suggest that
"labeling practices" that we don't use as documented create
confusion about the appropriate time and circumstances under
which a standard should be implemented, how mature the
specification actually is, and so on.   We've encountered a few
situations in which organizations have refused to implement
standards, or argued for substituting their own specifications,
because our "standards" are only "Proposed".  It is a matter of
debate, of course, how frequent those situations actually are
and how often, when that claim is made, the organization
involved would just hunt for a different excuse when that one
was not available.   But I suggest that cleaning things up --as
long as the marginal cost is low-- would eliminate a source of
reduced utility.  

I consider the timeliness and quality issues above, and the one
discussed below, to be far stronger justifications for the ISD
idea and spending time on it.

> Explain how the utility of the IETF to the community will be
> improved by our  fixing this.

We are in a situation today in which many of our specifications
are not really self-contained.  Some might even suggest that few
are. This has created a procurement nightmare in which
organizations who would like to procure and specify products
against IETF standards have few ways to figure out what to
specify.   That results in either their using third-party guides
(which we might or might not view as correct), guessing (and
some spectacularly silly errors have been made as a result), or
looking to other bodies whose specifications are more
comprehensible.  In theory, we could solve that problem with
comprehensive Applicability Statements, but, in practice, those
have turned out to be too heavyweight an effort and almost
impossible to get produced.   The hope is that, by use of prose,
cross-references, unification of related specifications under a
single umbrella document, and so on, the ISDs will provide us a
tool to improve on this situation and will actually do so.   And
that would, indeed, significantly improve utility.

Now, whether or not the ISD idea will actually accomplish
anything is very much an open question.   A great deal depends
on whether the IESG (particularly) and the community generally
get behind it.   The idea can easily be starved to death in all
sorts of major and minor ways.  But the people who have
advocated it and been working on it have been motivated
precisely by issues of timeliness, quality, and
comprehensibility of our work and, at least on many days, remain
optimistic about its actually solving real and critical-path
problems.

     john

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

---

From: Dave Crocker <[email-masked]>
Date: Thu, 28 Apr 2005 18:12:00 -0700

John,

> > >  Proposals for upgrading/streamlining standards track in discussion
> > >  (i.e. newtrk and specifically the ISD proposal, but there's
> >  Another derailed activity.  Another activity that has nothing to do
> >  with  quality, timeliness or relevance.
>
>  Here we disagree, or I most assuredly would not be spending time on it.  I
>  believe that, properly implemented and used, the ISD work could result in
>  much faster track processes for corrections and minor alterations to
>  standards-track materials.  

Well, I can believe that it might have some of that effect.  And I guess that 
is why I've put time into the working group too, though the effort became 
typically protracted.  

What I do not believe is that the problems it remedies are anywhere near the 
core of the IETF's crisis in producing timely, relevant, useful output.

>  with issues on which consensus is already fairly clear, we should be able
>  to improve quality and timeliness and, in the process, free up cycles to

This presumes that the problems being remedied are a major source of 
distraction, but I do not believe they are.  

I believe working groups are unproductive because they lack sufficiently 
concrete, shared goals, a clear sense of the necessary, near-term 
deliverables, and an urgent sense of need to produce something useful.  

I believe the IESG is a problem because excellent engineers feel like doing 
engineering overseeing the process by a) getting others to do the work, and b) 
living with the imperfect decisions of those others.

Newtrk has nothing to do with any of these.

> >  Explain how current document labeling practises hurt the IETF's utility
> >  to the  Internet community.

>     I suggest that "labeling
>  practices" that we don't use as documented create confusion 

The IETF has been around long enough, and has affected sufficiently many 
people and organizations, that I suspect we can find an existence proof for 
almost any problem.  

That does not make the problem worthy of our attention, since we are, after 
all, limited in our resources.

Issues of misused labels or confused adopters rightly offends our 
sensibilities, but there has been no indication that it is a strategic problem 
to the IETF or the Internet community.  Certainly I have not seen anything 
like a groundswell of IETF rough consensus that it is part of our crisis.

>    But I suggest that
>  cleaning things up --as long as the marginal cost is low-- would eliminate
>  a source of reduced utility.

Bingo.  I entirely agree.  But this is a working group that has been around a 
long time and engaged in extensive discussion, mostly re-visiting the same 
territory many times.

That's not a low marginal cost.

> >  Explain how the utility of the IETF to the community will be improved
> >  by our  fixing this.
>  We are in a situation today in which many of our specifications are not
>  really self-contained.  Some might even suggest that few are. This has
>  created a procurement nightmare ...
>     The hope is that, by use of prose,
>  cross-references, unification of related specifications under a single
>  umbrella document, and so on, the ISDs will provide us a tool to improve
>  on this situation and will actually do so.   And that would, indeed,
>  significantly improve utility.

Yes, that would be a Good Thing.  But then, as the document iself notes, it's 
in the ballpark of what the STD was supposed to do.  And, yes, the ISD 
document views itself as tweaking things, rather than re-inventing.  But, oh, 
I see a new document series is called for.  That's not tweaking.  

In other words, yes I agree that you are talking about a change that could be 
a useful improvement.  I don't think it is at the core of our crisis, but I 
suspect the benefit of having it succeed would be quite large.

However, as you noted, there are significant critical dependencies.  And again 
my concern that it is a long way from a low marginal cost, with no effect on 
producing new, timely, useful specifications.  And that, I'm afraid, is what 
determines the real future of the IETF.

  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net

---

From: Dave Crocker <[email-masked]>
Date: Thu, 28 Apr 2005 21:09:16 -0700

>  I believe the IESG is a problem because excellent engineers feel like
>  doing engineering overseeing the process by a) getting others to do the
>  work, and b) living with the imperfect decisions of those others.

sigh.  

typo:

engineering overseeing -> engineering, rather than overseeing

  d/
  ---
  Dave Crocker