Re: DSA Metrics & DUA [User Interface] Metrics (OSI-DS 34 & 33 version2)
Paul Barker <P.Barker@cs.ucl.ac.uk> Thu, 24 September 1992 11:38 UTC
Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa01697; 24 Sep 92 7:38 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa01693; 24 Sep 92 7:38 EDT
Received: from haig.cs.ucl.ac.uk by NRI.Reston.VA.US id aa04491; 24 Sep 92 7:42 EDT
Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id <g.01493-0@haig.cs.ucl.ac.uk>; Thu, 24 Sep 1992 11:46:55 +0100
Received: from bunnahabhain.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id <g.07221-0@bells.cs.ucl.ac.uk>; Thu, 24 Sep 1992 11:46:49 +0100
To: Jane Clark <jane@citr.uq.oz.au>
cc: osi-ds@cs.ucl.ac.uk
Subject: Re: DSA Metrics & DUA [User Interface] Metrics (OSI-DS 34 & 33 version2)
In-reply-to: Your message of "Thu, 24 Sep 92 15:39:44 CDT." <199209240539.AA10202@durian.citr.uq.oz.au>
Date: Thu, 24 Sep 1992 11:46:47 +0100
Sender: ietf-archive-request@IETF.NRI.Reston.VA.US
From: Paul Barker <P.Barker@cs.ucl.ac.uk>
Message-ID: <9209240742.aa04491@NRI.Reston.VA.US>
Jane, Thanks very much for the comments. I will incorporate fixes/suggestions in a revised version. Incidentally, following the call to the list the other day for people to fill in the Metrics for various systems, I actually completed the DUA metrics for the interface I have written myself. As a consequence of this, I have discovered that the DUA note will have to be revised somewhat as well! > I have some comments for consideration for the DSA Metrics document (OSI-DS 3 4): > > > re Question 14 (& probably 15): > === > > UK GOSIP for Directory has optional elements - > I think a list of the options that have been implemented should also be > requested. Will request list of options. > > > re Section 5.1: (last sentence): > === > > What is the feeling about the effect the particular implementations of each > of the protocols in the stack will have on performance? ... should there > be more questions about the environment such as the protocol implementations > used, the number of other systems on the LAN, etc.? I imagined that people would complete the Metrics to show off their implementations in as favourable a light as possible. I have thus provided a number of questions which describe the environment, and assumed that people would do their best within that framework. If there are other questions you could suggest ti tighten this up, I'd certainly consider them. > > > re Section 5.2.6 (and question 41): > === > > I am a little confused about what is required here (and how to express the > results). This is badly expressed. It stems from a modification to an earlier version. I'll clean up the text to just be an attribute addition. I can't see that the deletion would be substantially different, or that database idempotency is that important. > > re Question 46: > === > > a typo: I presume "1" is scored if more than _one_ association. Should certainly be more than 1! I can't remember what my original thoughts were here. I propose 10 as a number of associations meriting the mark. > > > re Section 10.3 Data Management: > === > > How about asking further questions such as: > > - how was the DSA populated with the 20 000 entries required > for the tests (and is this a method available to clients)? > > - how could the postal address of all the persons in the 1000 entry org un it > be changed (because it's just moved)? Two things here. Taking the second point first... This seems to a question on inheritance techniques. I agree it is important and will include something. The population of the DSA is an interesting question. I did have the idea of producing a kit which would allow the bulk-loading of a standardised database suitable for running these tests. Anybody wanting to apply the Metrics could use a publicly accessible service which would present the following prompts: DSA address> Username> Password> and 20000 entries could then be loaded by DAP. I think this in itself would be quite an interesting metric - i.e. does the DSA survive such a process? I had the idea of using the DMtools as the basis for this service. Unfortunatety I don't have the time to implement such a service at the moment. I'd be interested to hear if anyone thinks it is a useful idea. A volunteer would also be appreciated. > > > re Questions 75 & 76: > === > > I think there should be 2 categories for each of these questions: > > (i) interoperation with another DSA (ie using DSP) > (ii) interoperation with a DUA (ie using DAP). Quite agree. Will amend document. Thanks for your comments, > > > Regards > Jane > Paul