Re: review of mhsds docs, possible companion document

Steve Kille <S.Kille@isode.com> Mon, 11 April 1994 07:48 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01750; 11 Apr 94 3:48 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01746; 11 Apr 94 3:48 EDT
Received: from mercury91.udev.cdc.com by CNRI.Reston.VA.US id aa08066; 11 Apr 94 3:48 EDT
Received: by mercury.udev.cdc.com; Mon, 11 Apr 94 02:48:12 -0500
X-From: S.Kille@isode.com Mon Apr 11 02:48 CDT 1994
Received: from zeus.cdc.com by mercury.udev.cdc.com; Mon, 11 Apr 94 02:48:05 -0500
Received: from glengoyne.isode.com by zeus.cdc.com; Mon, 11 Apr 94 02:47:53 -0500
To: Allan Cargille <cargille@cs.wisc.edu>
cc: mhs-ds@mercury.udev.cdc.com, klensin@infoods.mit.edu, erik.huizer@surfnet.nl
Subject: Re: review of mhsds docs, possible companion document
Phone: +44-81-332-9091
In-reply-to: Your message of Tue, 05 Apr 1994 18:20:36 -0500. <9404052320.AA16432@calypso.cs.wisc.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <8445.766050558.1@glengoyne.isode.com>
Date: Mon, 11 Apr 1994 08:49:21 +0100
Message-ID: <8446.766050561@glengoyne.isode.com>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Steve Kille <S.Kille@isode.com>

Allan,

Thanks for this input, and also for the detailed and useful comment in
your subsequent messages.

I do not know what happened in Seattle, but would like to respond to
your message now.

First, I think that an overview/tutorial document as you suggest is a
good idea.  For complex specifications, it is usually a bad idea to
mix tutorial and specification.  Two good examples of this split are
ASN.1 (tutorial by Doug Steedman) and RFC 1327 (tutorial by Jeroen
Houttuin).   I think that evolving such a tutorial independent of the
spec, would also be a useful introduction for those on the outside.
I think that your offer to do this is very welcome.


Second, the problem of reviewing a complex and new specification.   I
see no easy solution here.   To me, the acid test is implementation.
Two independent implementations have been done.    Feedback from these
implementors gives me reasonable confidence about the basic soundness
of the specifications.   It will need the results of longbud to verify
(or not) the soundness of the overall architecture.   This needs to be
coupled with expert review - and for the individual expert this means
substantial effort to get to grips with the specifications.  


In passing, I'd like to comment that I think that this will be a
growing problem.  I believe that as the distributed application
architecture grows, there will be an increase in complexity to take
into account a wide range of requirements (look at SNMP V2 as another
example).  The specification is complex, but the complexity is made up
of much detail and there is sound reason for the detail.  As
complexity grows on the ox-cart -> porsche spectrum, the engineering
expertise requirements to participate will continue to increase and
become more specialised.



Steve Kille