Re: [NEWTRK] An updated ISD proposal

[Douglas Otis <[e-mail]>]

On 7/14/10 8:02 PM, Brian E Carpenter wrote:
>  Let's see if that old newtrk list is still there...
>
>  As I was in 2005 (believe it or not), I am still generally
>  sympathetic to the ISD concept. The concerns expressed in 2005 by the
>  IESG were quite wordy, but they were basically about a perception of
>  increased complexity and added (bureaucratic) workload. See
>  http://www.ietf.org/mail-archive/web/newtrk/current/msg00991.html
>
>  So, I guess the question is whether the updated proposal responds to
>   those points. It does clearly put the *responsibility* for the ISD
>  series on the IESG, as part of its standards-approving role. That's
>  reasonable, but what about workload?
>
>  I think we could minimise and distribute the job of collating the
>  information for a new or updated ISD by placing the responsibility
>  for *drafting* the ISD explicitly on the document shepherd. That
>  would automatically distribute the workload to the people best
>  placed to execute it.  As John notes in the draft, the information
>  needed is already there, in WG email and minutes, in most cases. So
>  collating it would really not be a big burden on the shepherd. In
>  fact, the draft ISD could become a required component of the draft
>  writeup that the shepherd must already provide to the cognizant AD.
>
>  My other high level comment is mundane, but even to test the idea
>  out, we need good tools support. Without that, we can be certain that
>  nothing will happen.
>
>  Regards Brian
It should not be surprising to find that I support the first option, as 
did many within the Newtrk WG at the time.
  ,---
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.
'---

In the days of the Internet explosion, many proclaimed one year of 
Internet Time was equivalent to seven in other endeavors, and that 
anything publish in a book is out-dated.  The Internet has made 
newspaper's daily reporting seem like yesterday's news, which it is of 
course.  The IETF is holding the tail of a tiger racing through a 
jungle.  The weighty ISD, as opposed to the SRD approach, assumes this 
tiger slows down, and that it can be guided by intricate pictures 
painted from images seen in a rear view mirror.  Who are these Artisans?

The IETF is not a traditional standards body.  The highly formalized ISD 
might weaken the grip on the tiger's tail in what might be seen as an 
effort to bolster egos.   Perhaps the attitude that some hold for books, 
is more true for documents proclaimed as a "standard" when it comes to 
the Internet.  The speed of change has made it obvious the constantly 
changing RFC references is not friendly to those who want their 
information one click away.  No one is willing to waste their time.  The 
concept behind the SRD effort was to solve the unfriendly reference 
issue, while also enabling a type of status to be conveyed that could 
replace the broken three tiered scheme that demonstrates obsolesce more 
than standardization.

While the latest effort by John offers a "degraded" version of the ISD, 
it encumbers what should be a light weight and easy referencing scheme.  
Those wanting to write their own ISD type of document can always do so 
as an RFC.

-Doug













>
>  On 2010-07-06 05:11, John C Klensin wrote:
> > Hi.
> >
> > As mentioned in the analysis of draft-housley-two-maturity-levels I
> > posted yesterday, I've made a pass through the old (NEWTRK-vintage)
> > ISD specification.  A new version is in the posting queue as
> > draft-klensin-isdbis-00.
> >
> > While the flavor and much of the text of the old version is still
> > present, it has been significantly revised to address both some of
> >  the issues raised in the last few weeks and the concerns about
> > workload raised by the IESG of five years ago.
> >
> > In particular:
> >
> > * The "providing information about a document" (the maturity level
> >  issue) and the "grouping documents" (the STD issue) are given
> > equal weight.  * A lighter-weight transition plan is incorporated.
> > * ISD numbers (to be assigned to anything reaching the
> > standards-track) and ISD documents are separated (we may want to
> > change the name if this goes anywhere).   The latter are required
> > only for specifications for which information that supplements the
> > RFC is, or should be, required anyway, e.g., interoperability
> > reports, descriptions of relationships to older versions,
> > descriptions of relationships of multiple documents that make up a
> > single standard.  * The minimum information required in an ISD
> > document (if one is required at all) is capable of being
> > automatically generated.
> >
> > As the last NEWTRK ISD document and discussions indicated, it is
> > always possible to dispose of a proposal like this by nit-picking
> > at the details and ignoring the larger picture or by complaining
> > that insufficient details have been provided.  I've tried to strike
> > a better balance in this version than the earlier one had, but I
> > can only hope that people will try to understand the principles and
> > that, while I've proposed a combination of details that I believe
> > will work, details can always be tuned.
> >
> > It is long (largely as a result of including enough detail to be
> > taken seriously), but, if one believes that the problems with the
> > system run a little deeper than the descriptions in
> > draft-housley-two-maturity-levels and that they deserve a more
> > comprehensive approach rather than slapping on patches of
> > terminology and levesl, it may be worth having a look.
> >
> > regards, john
> >
> > _______________________________________________ Ietf mailing list
> > [e-mail] https://www.ietf.org/mailman/listinfo/ietf
> >
>  _______________________________________________ NEWTRK mailing list
>  [e-mail] https://www.ietf.org/mailman/listinfo/newtrk