The OSI-DS Naming Survey

Steve Hardcastle-Kille <S.Kille@cs.ucl.ac.uk> Wed, 22 January 1992 17:49 UTC

Received: from nri.reston.va.us by NRI.NRI.Reston.VA.US id aa13438; 22 Jan 92 12:49 EST
Received: from bells.cs.ucl.ac.uk by NRI.NRI.Reston.VA.US id aa13431; 22 Jan 92 12:49 EST
Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id <g.04307-0@bells.cs.ucl.ac.uk>; Wed, 22 Jan 1992 17:26:48 +0000
To: osi-ds@cs.ucl.ac.uk
Cc: Dave Piscitello <dave@sabre.bellcore.com>
Subject: The OSI-DS Naming Survey
Phone: +44-71-380-7294
Date: Wed, 22 Jan 92 17:26:47 +0000
Message-ID: <930.696101207@UK.AC.UCL.CS>
From: Steve Hardcastle-Kille <S.Kille@cs.ucl.ac.uk>

This has been buried for a while, so let me dig it out!

This is the text of the orginal survey on progression of OSI-DS 12, which
if you remember was  about to be submitted as an RFC, and was then
filibustered by Christian.   

The consequences of this was a survey that was sent around to the WG.
I append:

1) The survey question
2) My summary of the answers (I can make available the list of answers
for anyone who wishes to analyse the details)
3) My proposed course of action in light of the survey results

I will produce a new I-D, which will be discussed at the WG3 meeting
in Brussels next week, and again at the IETF in San Diego.    I hope
that we can then get this out.


Steve


------- Forwarded Message

From:    Steve Hardcastle-Kille <S.Kille@uk.ac.ucl.cs>
To:      osi-ds@uk.ac.ucl.cs
Subject: Survey on OSI-DS 12
Date:    Wed, 06 Nov 91 10:52:21 +0000

I'd like to get some feeling of the WG on how to progress OSI-DS 12

Please reply to me, and I will summarise

Note that this is an informational document, giving guidelines.  It
will not be a standard.


Q1) Should OSI-DS be submitted as an RFC soon?

YES/NO/If concensus on Q2 and Q3 is achieved


Q2) Are you happy with the text on the top level of the DIT


Q3) On the choice between the proposed text (PB/SH-K) and Christian's proposed
ammendments (CH) please note YES/NO/Acceptable to each of the following
options

A) PB/SH-K
B) Recommend PB/SH-K, but note CH
C) Note both and do not recommend
D) Recommend CH, but note PB/SH-K
E) CH  


Steve

------- End of Forwarded Message


Survey results:

Q1)  Yes: 9  No: 0  Yes if concencus on Q2/Q3: 6

Q2)  Yes: 12  No: 2

One no required resolution of  l=Europe.   The other objected to the
DNS hierarchy.   A number of small suggestions were made.


Q3)  
   A) Yes: 9	No: 3	Acceptable: 1
   B) Yes: 2	No: 3	Acceptable: 8
   C) Yes: 2	No: 8	Acceptable: 3
   D) Yes: 1	No: 9	Acceptable: 2
   E) Yes: -	No: 11	Acceptable: 1


My analysis.   

Q1) There is a strong WG view to get an RFC out.   I will successfully
argue that there is concensus on Q2/Q3, and so this is really a note
to the Area Directors that this I-D is pretty much ready.   The WG
will do a face to face check in San Diego.

Q2)  The text has broad acceptance.  A few comments:
   1) L=Europe stays.   There was only one objection to the retention
	of l=Europe (in conjunction with a Yes vote for the text).   I
	think that whilst I can see arguments against it, there are
	strong arguments for it, and no general problems caused by its
	use.   There are potential problems of registering in this
	area, and this should be pointed out to any organisations
	which choose to register there.   We should be inclusive, and
	let the market decide.

   2)  Removal of DNS tree.  This position has not had widespread
 	support, and so the current text is retained.

   3) I will add Andrew Waugh's excellent suggestion on relating the 
	approach to national policy.  I believe that this view had
	general support.   


Q3) The key problem here is that there are two views on the table,
which have a different model and have diametrically opposite
recommendations.   There is not really a compromise.

There is a majority in favour of the PB/SH-K approach.   Exclusive
use of this approach seems to have the numeric favour over also
documenting the alternative.   A) and B) have the same number of nos,
and I will analyse this a bit further.  No-one voted NO to both A and B.

Those that voted yes for B and no for A, argued that there was a
serious alternative, which should be noted rather than ignored.

Those that voted yes for A and no for B, argued (I quote one of them):
"No. Adds confusion. Decide on one, don't wimp out and say  "this is the
recommended way, but if you don't like it, here's another way ...""

I have some sympathy with both lines.  I propose to go for B, but make
the recommendation for the PB/SH-K version unequivocal, whilst fairly
stating the opposing view.  (I guess that I'm wimping out!) I hope
that everyone will be sufficiently happy with this line to allow the
document to progress now.

I will be submitting an I-D in due course, for discussion at the
upcoming meetings.



Steve