Subject: draft-zhao-slp-da-interaction-07.txt

From: James Kempf <[email-masked]>
Date: Fri, 21 Jul 2000 12:48:54 +0-900

I've got some comments on this:

1) I suggest changing the terminology from "Action-ID" to "Message Type".

2) On pg. 5, the No_Action description should have more telling what
it does. When I first read the text, I couldn't figure out why you'd
want it. Later in the paper, I found out.

3) What does a nonmesh DA do with the extension? This will be determined
by what range the extension is in. Related to this, before this goes
to draft, it will need an extension number.

4) On page 6, and following, the designation of DA 1 and DA 2 is confusing,
and switches around on latter pages. Why not call it originating DA and
receiving DA, or something like that. At a minimum, DA 1 should be the
one that first comes up, not DA 2.

5) I don't understand why the Peer_Conn_Indication and Peer_DA_Indication
can't be done in one message. 

6) The caveat about two DAs bringing up a connection at the same time
is serious. What happens when this occurs? A standard must be able
to handle such contingencies.

7) It seems to me like the Data_Dump_Rqst extension really wants to be
a full fledged new message rather than an extension on a DAAdvert.
I think if this is going to be a standard, we need to consider adding
it as a new message.

8) On pg. 9, section 5.3, I think the first paragraph should be a list.

9) Is forwarding of DAAdvert messages really necessary? I think the 
text needs more motivation.

10) The discussion of using a mesh-enhanced DA to allow a DA to manage
access to other DAs is confusing. We actually do this in the Solaris
slpd, so I understand what you are talking about, but I think this
discussion should either be included as part of the standard or removed
from the paper. 

11) pg. 13, "enhanced DAs normally. It dose NOT forward them." Typo.

			jak

---

From: Weibin Zhao <[email-masked]>
Date: Fri, 21 Jul 2000 11:14:25 -0400 (EDT)

Hi James,

Thanks for your comments. I try to answer some of your questions. 

> to draft, it will need an extension number.

A non-mesh DA just ignores this extension. There is an extension ID
given in section 8, page 13. It is 06.

> one that first comes up, not DA 2.

The number here is not related to DA coming up time. To be more clear, 
I will update these figures.
 
> can't be done in one message. 
 
They can be combined into one message. However, they serve for different
purposes and Peer_Conn_Indication is sent only in one direction. Separating
into two messages is more clear and make the implementation easier.

> to handle such contingencies.

If two DAs have two peering connections, they will work fine. Each
DA forwards messages using its own peering connection. This is not
efficient compared with one shared peering connection. The possibility
that this happens is really small.

> text needs more motivation.

The overhaed of forwarding DAAdvert is small, and it helps when
multicast is not supported or a DA's DAAdvert multicast can not
reach all of its peer DAs.
 
> discussion should either be included as part of the standard or removed

I am not quite clear what you mean for this. Forwarding DAAdvert helps
peer DAs to know each other. There is no other purpose for doing this.

> 11) pg. 13, "enhanced DAs normally. It dose NOT forward them." Typo.

I do not find where the typo is.

-Weibin

---

From: Terry Lambert <[email-masked]>
Date: Fri, 21 Jul 2000 16:25:16 -0700

> I do not find where the typo is.

"dose" should be "does".

-- Terry Lambert
-- Whistle Communications, Inc., an I.B.M. Company
-- [email-masked]
-------------------------------------------------------------------
This is formal notice under California Assembly Bill 1629, enacted
9/26/98 that any UCE sent to my email address will be billed $50
per incident to the legally allowed maximum of $25,000.