Re: [NEWTRK] An updated ISD proposal

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

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
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
> 