Re: Directory Services Work coordination proposal

John Curran <> Sat, 13 November 1993 05:12 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa25264; 13 Nov 93 0:12 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa25258; 13 Nov 93 0:12 EST
Received: from by CNRI.Reston.VA.US id aa03809; 13 Nov 93 0:12 EST
Received: by (4.1/UCD2.05) id AA14927; Fri, 12 Nov 93 20:15:42 PST
Received: from by (4.1/UCD2.05) id AA13583; Fri, 12 Nov 93 19:53:52 PST
Message-Id: <>
Received: from by id aa08958; 12 Nov 93 22:55 EST
To: Simon E Spero <>
Cc: "Barry M. Leiner" <>, "Erik Huizer (SURFnet BV)" <>, RARE & IETF OSI-DS wg <>,,
Subject: Re: Directory Services Work coordination proposal
In-Reply-To: Your message of Fri, 12 Nov 1993 18:52:57 -0500. <>
Date: Fri, 12 Nov 1993 22:51:53 -0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: John Curran <>

] From: Simon E Spero <>
] Subject: Re: Directory Services Work coordination proposal
] Date: Fri, 12 Nov 93 18:52:57 -0500
] ...
]   The other two hierachies, geographical and topological, are more useful
] for yellow-pages style searching. The topological hiearchy corresponds to
] a sites network connections. If I wanted to find a copy of gnu emacs, 
] the best result is the one closest to me by network. By starting at my 
] local server, and then spreading outwards by following topology links, I'll
] soon find the closest copy. This feature will be particularly important when
] the directory is linked to a caching file-store. This hiearchy offers a 
] solution to the "soft-pages" problem.

    I agree that multiple hierarchies could be very useful, but I'd
like to insert a side node regarding topologic information:

   As the network does not currently provide adaquate information regarding 
the path to a destination (e.g. "what are the delay, bandwidth and reliability
characteristics of the path between my system and"?), it is perfectly
reasonable to presume that topological "closeness" implies a better choice.

   Long term, it would be preferable if the network could actually answer
some questions regarding the path to a given destination.  This would allow
the client to make a decision based on it's priorities.  For example, you may 
have different criteria for the "site to retrieve RFC from right now"
and the "site which my archive mirrors from".

   Does this make any sense?