RE: NSSRs (Re: LAST CALL: draft-ietf-ldapext-referral-00.txt)

[Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>]

Believe it or not - some agreement here.
NSSRs to me seem a bit of a curiosity. As an NSSR knows the protocol
connection knowledge, but not the directory naming context,  I would
think that if directories are to provide deterministic name based
transactions over a distributed environment then NSSRs would or could
prevent that. In addition if one is configuring another DSA, one would
also check its naming context - because one would not want a duplicate
DSA to be configured in. That would be like having two IP Users with the
same IP address. 


NSSRs in my view introduce non determinsitic system characteristics and
from an operational perspective - wont be used.

regards alan

> -----Original Message-----
> From:	Harald Tveit Alvestrand [SMTP:Harald.Alvestrand@maxware.no]
> Sent:	Tuesday, March 24, 1998 9:47 PM
> To:	D.W.Chadwick@iti.salford.ac.uk; ietf-ldapext@netscape.com; Tim
> Howes
> Subject:	NSSRs (Re: LAST CALL:
> draft-ietf-ldapext-referral-00.txt)
> 
> Looking at consequences, here's what I see from my 10.000 foot
> perspective:
> 
> - Either referrals, as specified by this WG, support NSSRs or they do
> not
> - If we support NSSRs now, we will never get rid of them.
> - If we do not support NSSRs now, adding support for them will require
>   a protocol revision, and possibly changes to the URL format.
> 
> If we DO NOT support NSSRs, the consequences are:
> 
> - When interworking with networks of X.500 DSAs, the X.500 DSA (or
>   rather the LDAP/X.500 gateway) has to chase an NSSR until it becomes
>   (possibly a set of) specific referrals.
> 
> If we DO support NSSRs, the consequences are:
> 
> - LDAP servers can delegate whole subtrees while keeping the base
> entry
>   on the same server.
> 
> - LDAP/X.500 gateways get a little easier to write.
> 
> My personal preference is for keeping LDAP simple and putting burdens
> on the gateways; like David, I think NSSRs are costly in terms of
> complexity of the infrastructure and specifications.
> 
>                             Harald A
> 
> -- 
> Harald Tveit Alvestrand, Maxware, Norway
> Harald.Alvestrand@maxware.no