Subject: re: draft-zhao-slp-da-interaction-00.txt

From: Weibin Zhao <[email-masked]>
Date: Sun, 13 Feb 2000 19:14:21 -0500 (EST)

Eric,

Thanks a lot for your valuable comments for the draft. 
I am sorry that I could not answer your questions timely.
Now I am trying to catch up.

>   +----+             SrvDeReg   +-----+
>   |    | --- Unicast SrvReg --> |     |            SrvDeReg   +-----+
>   | SA |                        | DA1 | -- Forward SrvReg --> | DA2 |
>   |    | <-- Unicast SrvAck --- |     |                       +-----+
>   +----+                        +-----+
>                                    |               SrvDeReg   +-----+
>                                    +------ Forward SrvReg --> | DA3 |
>                                                               +-----+

According to this diagram, no SrvAck messages are sent from DA2 and DA3
back to DA1. This is for the following considerations: First SrvReg 
by SA should be made uniformly to all DA in the registration scope. 
If DA1 fails to accept the SrvReg, it should not forward the SrvReg 
to its peers. In other words, ONLY successful SrvReg messages made
to DA1 are forwarded by DA1. Second, since a forwarded message is via 
TCP, a reliable channel, no ack is needed. Third, from the perspective 
of the SA, it sends one SrvReg, and receives one SrvAck. There is no
difference as of whether DAs are mesh-enhanced or not.

I will get back to you on other questions soon.

Weibin

---

From: Erik Guttman <[email-masked]>
Date: Mon, 14 Feb 2000 10:48:01 +0100 (MET)

> back to DA1. 

I think DA2 and DA3 should return acks, I just omitted them from the figure.
The Acks are needed since the registrations may have some problem with them.
For instance, if DA3 returns DA_BUSY, then maybe DA1 has to reschedule...
If DA2 complains that the authentication is bad, this should be logged so
that the DA can be reconfigured, etc.

> This is for the following considerations: First SrvReg 
> to its peers.

I agree.  

> In other words, ONLY successful SrvReg messages made
> to DA1 are forwarded by DA1. 

Yes.  Its tempting to consider that DA1 should only return SLP_OK if
DA2 and DA3 both accept the reg, too.  But I think the rules are
too restrictive in this case.  DA1 could continue to try to register
asynchronously with DA2 and DA3, for instance.

> Second, since a forwarded message is via 
> TCP, a reliable channel, no ack is needed. 

But there could be errors and in particular DA_BUSY could be returned.
It really costs more to not have Acks than to have them, since the code
is already in place and the protocol demands Acks.  I think you lose a
lot by taking them out and you have to modify SLP to do it.  A lose lose
proposition.

> Third, from the perspective 

That is the main point!  Agreed.
 
> I will get back to you on other questions soon.

Excellent.  I look forward to them,

Erik