Draft minutes of OSI-DS Meeting

Steve Hardcastle-Kille <S.Kille@isode.com> Sat, 08 August 1992 14:09 UTC

Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa05598; 8 Aug 92 10:09 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id ab05594; 8 Aug 92 10:09 EDT
Received: from haig.cs.ucl.ac.uk by NRI.Reston.VA.US id af08676; 8 Aug 92 10:09 EDT
Received: from glengoyne.isode.com by haig.cs.ucl.ac.uk with Internet SMTP id <g.03449-0@haig.cs.ucl.ac.uk>; Fri, 7 Aug 1992 10:18:31 +0100
Received: from localhost by glengoyne.isode.com with SMTP (PP) id <01558-0@glengoyne.isode.com>; Fri, 7 Aug 1992 09:39:50 +0100
To: osi-ds@cs.ucl.ac.uk
Subject: Draft minutes of OSI-DS Meeting
Phone: +44-71-223-4062
MIME-Version: 1.0
Content-Type: text/plain; charset="iso8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 07 Aug 92 09:39:47 +0100
Message-ID: <1556.713176787@isode.com>
From: Steve Hardcastle-Kille <S.Kille@isode.com>

Please send comments.   I would welcome a volunteer to go over the afternoon
notes and translate them into a form which will be cleare to someone who
has not attended the meeting.   

Steve

OSI-DS Meetings: 8th meeting of the IETF Directory Services Group

July 13th 1992, Dan Diego

Minutes  by Justin C. Walker, Doug Simmons, and Steve Hardcastle-Kille

Attendees:

To Be Supplied  

Notes, OSI-DS 7/13 - These are for the AM session only.

Comments on agenda:
Mark Knoper sent apolgies for non-attendance and then turned up.

Here follow comments on the minutes from San Diego (OSI-DS-
MINUTES 7), particularly relating to action items from that meeting:

Regarding maintenance of RFC-1274, it is Steve and Paul Barker who 
will be involved, not Colin as the minutes claimed.

Eric Huizer's strategy document is ready (comments will be made 
later in the minutes).

Chris's documents (OSI-DS 14, 16, 17, 19) have not been revised.  
This will be done by the next meeting.  Mark Knoppe has taken up 
the network schema.

Documents OSI-DS-12, 23, 24 have been revised and submitted to 
the IESG.  As suggested in the previous meeting, Steve Hardcastle-
Kille read NADF 175 (which has been revised to NADF-(***Didn't get 
the reference***).  He cleared up some misconceptions regarding he 
NADF position, but overall, his position did not change from the last 
meeting.

Wengyik continued to work on interoperability issues.  However, he 
had no input, since he was not present.

There will be a NADF meeting next week (that is, the week of 7/20).

The QOS experiments will be discussed as indicated in the agenda.

The JPEG schema was reviewed.  However, the Schema group had not 
yet formed, so this item was continued.  Paul Barker was to establish 
the schema group, but this had not done this because of overload due 
to Steve's departure to the ISODE Consortium.  Resources were 
requested (volunteers were solicited; no response was heard from 
Russ and Mark).

The Character Set experiment wasn't discussed because Geir 
Pederson wasn't present.  The action was continued.

Tim Howes brought us up to date on the DIT Counting effort.  The 
code has been written, and will appear in the next ISODE Consortium 
release of QUIPU.  The item was continued.

Work on schema publishing was completed and will be discussed 
later.

The action item on preferred names was continued (no one was 
present to speak on the subject).

(***Missed something***)

Steve H-K finished the revision of RFC-1279 , with Wengyik 
consulting.  The paper has not actually been updated (in its electronic 
form)..  It will be circulated.

The lightweight protocol note (LDAP) was revised and 
circulated.

Steve Hardcastle-Kille looked into possible ISO alternatives to SOS 
(the Simple OSI Stack).  There are no current ISO proposals 
addressing the SOS issues, but John Day (from BBN) has circulated a 
document (in OSI circles) on the OSI upper layers.  Reviews are not 
complete, but this document does not seem to be an answer.

There were no Matters Arising.

We therefore moved right into the liaison reports.

1. RARE (Eric Huizer)
As reported at the last meeting, WG3 is no more.  The new RARE 
structure has eight working groups, of which one, WGNAP (the 
Working Group for Network APplication support), will undertake 
directory services (as well as time protocols, etc.).  A major problem 
is that, while a Chair has been identified and wants to undertake the 
work, he can't get permission to do the job.  WGNAP hopes to meet in 
November.  A distribution list has been set up for other than 
directory service issues.  WGNAP will continue to use OSI-DS for its 
directory service discussions.  The WG has small budget from RARE, 
provided they can come up with a priority list of tasks.  This could be 
applied to travel.

2. OSI/CCITT (Ken Rossen)
There were two significant events to report.  ISO 9594 passed to DIS.  
The most significant change was in the area of access control 
(replication and an extended information model).  DISP (shadow); 
DOP (binding) are new protocols.  An access control context is a 
combination of levels of access control.  The US 
pushed successfully for simplified access control: this only allows a 
decision to be made at administration points (new in model); a 
decision isn't overridden by lower levels of the tree.  As of the last 
editing meeting, merged text was produced.  Unfortunately, the 
circulated stuff was a mess.  There is a good copy, dated 12/25/91 
(hence it is called "the Christmas text").

The second event occurred in May.   When ISO SC21 met in Ottawa, 
the directory services group also met, and changes to the standard 
were discussed (with a 2 year target, down from the usual 4).  Use of 
OSI management (CMIP) to manage the directory was put on hold, 
since the responsible party (from the US) resigned.  Work on 
authentication could be undertaken as there is support for small 
changes, e.g., certificate revocation.  This will wait for the next 
meeting to commit effort to this work.  There was a feeling that there 
is need for closer work with (ISO) security folks for a more 
sophisticated security model.  Given upper layer security services, 
there is a need for a scheme to apply to directory services.  Also, 
there is a new edition of ASN-1 encoding rules, which could effect 
directory.  Distinguished encoding rules were introduced that are 
different from those currently used by the directory.  There is need 
to work out conflicts.  This could affect digital signatures.  The 1992 
X.500/9594 should progress at the next editing meeting in Orlando, 
in the fall of `92 (this will involve serious cleanup.  Rows of ducks 
will be set up at a US meeting in Nashua this week.).

3. OIW (Russ Wright) 
The OIW continued work on standardized profiles for DAP, replacing 
agreements from the OIW and EWOS.  They are on schedule for 
results by the end of year.  A joint meeting was held with the X400 
SIG to look at MHS and the directory.  Their desires right now are 
unclear, but they will provide a clearer spec.

The IGOSS document was reviewed.  This is a combined document 
representing input from GOSIP, the power industry, and the 
manufacturing industry.  This requires `92 directory extensions, 
including replication.  They were asked to review POSIX documents 
relating to directory services.  The documents themselves are in the 
mail.

4. DISI (Chris Weider)

Documents describing advanced directory usage and how to get
registered in the directory have been worked on, but not circulated.
A revision RFC-1292 has been worked on Four new papers have been
prepared: a pilot catalog, a description of DIT setup, the directory
naming philosophy, and a schema for restaurant information.

5. AARN Mark Prior

There is not much happening at this time.  AARN is not willing to 
commit to further work, nor are they willing to say no to further 
work.  They are waiting for December (***Why?***).  There are 
currently 40000 entries in their directory, and they have just added 
affiliates.  Master and slave machines will be soon be upgraded.

6. NADF (Marshall Rose/Einar Stefferud)
The last NADF meeting was in April, the next will be next week 
(7/20).  Discussion of vendor plans at the last meeting was exciting 
(depressing?).  Several documents are available.  One provides a 
naming scheme for a country (discussing principles), and a second 
provides an application of these principles to the US.  A third 
discusses the theory and practicality of directory security.

This latter is up for more debate.  There is a desire for simple 
authentication, but this may be difficult to protect from replay 
attack.  The  recommendation may be for protected passwords.  The 
documents should become RFCs (but some can't even seem to be put 
into the politically *in*correct PostScript format).  Marshall will 
provide copies for Steve Hardcastle-Kille.  None of the twelve 
vendors present supported any but simple authentication.  None 
would commit to supporting `92 extensions (except one who was 
planning to support the extended information model).  In short, 
things don't seem to be going very well (according to public comment 
at the meeting.  This is born out by Ken's observations at COS).  There 
seems to be more positive support for simplified access control (over 
the basic version).

Ken noted that they think they've fixed NADF complaints.  Time was 
spent at the  Ottawa meeting on defect resolution (there is a 
directory implementer's guide; see Ken).  There seems to be some 
interplay between ISO, NADF.

As no pilot project representatives were present, we continued on 
with the rest of the agenda.
 
Eric Huizer: The Naming Guidelines document, the UFN document, and 
the  document defining string representation of UFN's were 
submitted in April to the IESG.  They are expected  to move forward 
by end of this month.

Eric Huizer: The strategy document (based on Steve's original) was 
much modified, based on comments received.  Most of the original 
was retained, but with editing and restructuring.  One of the main 
criticisms was references to other RFCs without indicating the RFC 
content.  Eric's solution was to pull the main points from the RFCs in 
question, using reference only for detail.  He added deployment 
details and requirements.  Therefore, there were a lot of references 
to DISI papers.  The ASCII version (as posted) was quite unreadable.  
Apologies were tendered, along with a promise to fix it.  Comments 
were requested.

One comment at the meeting: a possible extension involving the use 
of large data values was questioned.  The response was that this is 
only a *possible* extension, not a planned (or required) one.  An 
observation was made that all items in this section (of the document) 
could be termed controversial.  The main point is that the model is 
not rigid: if deployment experience indicates that a change is needed, 
it will be addressed.  


Regarding progress to ID-hood for the strategy document, the 
approval of the other authors is needed.  Then an informational RFC 
can be submitted.  Steve Hardcastle-Kille wants to see this done 
reflecting an IAB/IESG consensus (as was done, e.g., for RFC-920).  He 
wants the submission and publication to reflect IAB policy.  It is 
unclear what the tradition is.  It was felt that we should have OSI-DS 
consensus, so  a sense of meeting was taken; there were no votes 
against the document, but there were a large number of abstentions 
(from those who had not read it yet).  Eric will take changes, publish 
the new document as an RFC (both text and PS formats), and get it 
into the IESG stream.  The attendees seemed to favor not waiting for 
the next meeting, given the consensus here (all who had read 
approved).

Eric noted that none of the three documents mentioned earlier 
showed up on the IESG action list that he gets.  This was deemed to 
be a dropped ball.  Eric will follow up to determine how the ball got 
dropped and assure that it doesn't happen again.

Tim Howes: Some comments on the schema document, from Colin 
Robins (sent by email to the OSI-DS list), were distributed.  Given that the 
schema is rapidly changing, the idea of storing (a description of) the 
schema in the DIT has been investigated.  Tim looked first at the '92 
standard, which was very complicated.  The `92 information is in his 
document, but comments he's received indicate that it (the `92 
content) should be pared down.  The document talks about 
representing attribute. information in the directory, although no 
syntaxes were defined.  Although the document says this work will 
be a subset of `92, Tim doesn't think it really is.  We must decide on 
compatibility with `92 vs. having something "now ".

The question was asked: what are the areas of incompatibility? 
Among others, there is the attribute syntax, which is difficult to 
figure out.  From Colin: how does one go from an OID to an 
identification of information it represents?

It was noted that an OID tree may be useful by itself, independent of 
other uses.  There is a bootstrap problem with this.  The issue is 
where to find a description of information, and what is the efficiency 
hit?  Using well-known locations in the DIT may avoid a recursive 
upward walk of the tree.  This also assumes a configuration run that 
tells the DSA what well-known locations to check.  The directory 
doesn't do dynamic interpretations of OIDs.  It was observed that 
"compatibility w. 92" and "something that works" may not be 
exclusive.  Two actions resulted.  The first was to define the OID tree.  
The second was to revise the schema notes in light of the discussion.  
Tim took both.

QOS Experiments:  There was no change from the previous meeting.  
This work has not been a priority (although there is work 
"scheduled", to be done on Macintosh DUA).  Sylvain noted that code 
that he has seen doesn't match the RFC (which may have changed 
since he last checked it).  Tim wanted this taken off the agenda, since 
it isn't a priority.  He would like to surprise us with progress when it 
happens.

JPEG - The JPEG attribute is not in the schema, but there is code to 
handle it in ISODE.  Russ would like this to be its end.  Proposed to 
carry over to next time when the schema group is represented (and 
so it shall be).

Character Set (Geir Pederson was not present): Again, the schema 
group was an issue.  A discussion commenced on how to get this 
done.  IANA was suggested as a source of help.  A problem with this 
is that we would need to find someone with directory experience to 
take on some editing load.  It was recommended that we talk with 
IANA, then worry about the short term. 

Selection of the time and place for the next meeting  involved two 
choices: INTEROP (October in San Francisco), and the next IETF 
(November in Washington).  A vote marginally favored the 
November IETF meeting, and this was agreed on.  


LUNCH




Topic:  DSA and DUA Metrics (OSI-DS33 ,OSI-DS 34)

-  measure pilot projects' success

-  deliverables - metrics papers for:
     - DUAs
     - DSAs
     - Pilots' metrics

- no absolute measure of goodness or badness of DUAs;  there's
  SOME importance to the numbers,though.

  comments on these papers:

  - set up an FTP ID to keep the OSI-DS documents in for easy
  retrieval before these meetings. SEH to address.

  - DSA doc - need hands-on experience to tell if this document is
  really worthwhile and accurate. (comment by Eric Huizer)

  - DUA doc - section l2 (query resolution) not very clear what one
 should enter to initiate the query (comment by Time Howes)

  - DUA doc - 5 steps to enter a query as opposed to on line via UFN

  - BOTH - isthis a Consumer Reports on DUAs/DSAs? SEH - the user
  endorsement section contains the necessary feedback for analysis

  - BOTH - there were comments from Paul Andre, were they being
  incorporate?

  - DSA doc - section 5,need to discuss the environment - how can we
  measure implementations on different machines?  (comment by
                                                     TimHowes)
  - DSA doc - need more than lOO to 5OOO entries for accurate testing
  (comment  by Tim Howes)

  - DSA doc - need more discussion on security aspects (unknown)

  - BOTH - metrics will not be useful until they are tried
  out/tested against (unknown)

  - BOTH - make measurements available via informational RFC.

  - DSA doc - other implementations tested besides QUIPU?
  (comment by Sylvain Langlois)  (Pissaro(sp?), ICL, Dirwiz....)

  SEH - how many of us are responsible for DUA implementations?
  would it be worthwhile tomake these documents publicly
  available?  SEH to use RFC for informational test until next
  meeting for feedsback.

  *ACTION - Erik to do Siemens DSA
         - Tim and Russ will do DUAs we'll evaluate findings at next
	 meeting

  *ACTION - SEH to get these published as RFCs
             - everyone to see that these get filled in when DUA's
	     and DSA's tested

  comment - what's the difference between RFC l292 and DS 33 and
  34?  SEH: 33 and 34 much lower level (and more work to fill out|)
  SEH suggested that the vendor be asked if they filled out a 33 or
  34 before answering to RFC l292


  Topic : Representing Network Infrastructure Information in X.5OO
            (Mark Knopper)   Draft circulated

  Topic:  Soft Pages Project (Steve Hardcastle-Kille)

  Comment - IP name space:  defining an address hierarchy. You
  really don't need that, what advantage over a flat design?

  comment - network elements diagram is a network toplogy. What
  happens if that changes? (comment by Tim Howes)

  comment - (Mark Hopper)  not sure if this resolves the problem -
                              it is too inefficient.
	    - how do you get the bootstrap up and running?

  ACTION * - Mark Knopper to document how we might use this
              (where might the holes be)

  comment - this tree can be kept small just by keeping the DSAs
  'near' you in the DIT,as they are the only ones which should
  interest you for cost purposes.

  comment - need FTP address for this document (FTP.TOHOKU.AC.JP)

  comment - do we need a WG to address this problem?

  ACTION* Thomas Johansen and Mark Knopper to reconsider their
  approaches and attempt some kind of convergence.

  Topic: LDAP (OSI-DS 26, OSI-DS  27)

  comment - kerberos and simple authentication:  do we think this is
  worthwhile and should it be added to the document before it
  becomes an RFC? (Tim Howes)
  SEH - because it is implemented and deployed, then it should be
                                                     documented.

  comment - we should submit this to the standards committee asap.

  comment - suggestion that we have Christian look at it, as he has
  strong views on the subject.

  Topic:  DSA Naming (OSI-DS l3)

  issue:  avoiding deadlock

  comment - the DSA must be named higher in the tree (country level)
  to prevent deadlock, but you do not insure uniqueness

  comment - Erik seemed to remenber opposition by the Pissaro
  group, but could not elaborate.

  comment - using subtrees seems to be the way we fix things we
  can't fix via X.5OO

  ACTION*  SEH to re-write the paper to using non-QUIPU language and
                                                         references.

  comment - Erik not comfortable, seems like a way to fix a design
  problem in QUIPU.  Need input from other DSA vendors.

  ACTION*  SEH to drop this as an OSI-DS item and take it up as a
                design issue withISODE



ACTIONS


ACTION CLW Update OSI-DS 14, 16, 17, 19 (carried forward)

ACTION EH  Progress Naming Guidelines, DN Syntax, UFN, and LDAP and
	LDAP Syntaxes as RFCs


ACTION - Erik to do Siemens DSA
          - Tim and Russ will do DUAs we'll evaluate findings at next
	 meeting

ACTION - SEH-K to get these published as RFCs
       - everyone to see that these get filled in when DUA's
       and DSA's tested


ACTION - Mark Knopper to document how we might use this
        (where might the holes be)


ACTION Thomas Johansen and Mark Knopper to reconsider their
        approaches and attempt some kind of convergence.



ACTION  SEH-K to re-write the paper to using non-QUIPU language and
                                                         references.

ACTION  SEH-K to drop this as an OSI-DS item and take it up as a
                design issue with ISODE

ACTION   SEH-K  Revise Charter


ACTION   SEH-K/EH  Discuss IANA support for Schema Management


ACTION   TH  Write note on representation of OID Trees in Directory

ACTION   PB  Publish Metric Papers as Internet Drafts

ACTION   SRS  Collect DUA survey results and publish as I-D