Re: [Ldap-dir] DLAP Directorate review request for draft-dawkins-ldapext-subnot

["Spencer Dawkins" <[e-mail]>]

Hi, Kurt,

I'm replying to a question you asked, but my reply is probably also relevant 
to Steven Legg's question about subscription lifetimes.


> I am curious as to why firewalls and NATs are mentioned in the 
> applicability of the specification.  Does this extension not have the 
> same basic issues with firewalls and NATs that simple LDAP has?  That  is, 
> LDAP generally works just fine (*) through firewalls and NATs so  long as 
> they are configured to allow traversal, as most TCP-based  client/server 
> protocols do.  (* expecting issues with reverse NAT and  knowledge 
> references, and the like).

My understanding of this proposal (Peng is the expert on the proposal, I'm 
the guy who understands the IETF) is that the LDAP client would not close 
the TCP connection to the LDAP server, but would leave the TCP connection 
open, so that the LDAP server can send notifications in a timely manner.

This isn't normal LDAP-style TCP connection handling, as I understand it 
(please correct me if I am confused).

The alternatives would be

o having the LDAP client poll periodically to pick up notifications (as you 
visualized) - this wasn't chosen, because the goal is that notifications be 
delivered in a timely manner, or

o having the LDAP server open a TCP connection to the LDAP client - this 
wasn't chosen, because it trips over one-way firewall policies.

So I was imagining that we would have problems with firewall and NAT binding 
timeouts, etc. in ways that other LDAP operations would not. That's what I 
was thinking about when I added this section, just before we submitted.

Does this make sense? (And, if so, should this model of operation be stated 
more clearly in the draft? :-)

As for Steven's question - I believe that the LDAP server would remove the 
subscription if the TCP connection is closed, or reset due to unreachability 
of the client. Does this make sense, or would you prefer to see an 
LDAP-level unsubscribe operation?

I'd also like to thank you guys for the near-instantaneous feedback.

Spencer