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

From: [email-masked]
Date: Mon, 15 May 2000 19:28:51 +0430 (GMT+04:30)

Weibin,

Some comments on the -03 draft.

These comments apply to the abstract and introduction:

1. Style 

This scheme also greatly simplifies SLP service registration 
leading to a thin-client Service Agent (SA) implementation.

->

This scheme also greatly simplifies the implementation of service 
registration for a thin-client Service Agent (SA).

2. Style

Therefore, the scalability
   of an SLP system can also be enhanced.

->

The scalability of SLP is thereby enhanced.

3. Style

It is entirely backward
   compatible with SLPv2, and incremental deployment is supported.

->

All enhancements to SLPv2 presented in this specification are backward compatible with SLPv2, and incremental deployment is supported.

4. Section 4.1, correction:

   In SLP, each DA periodically sends DA Advertisement (DAAdvert)
   messages to the administratively scoped SLP multicast [3] address
   (239.255.255.253).
                  ^

add:

is the default address in the IPv4 local scope [M].

[M] is a reference to rfc 2365:

Network Working Group                                           D. Meyer
Request for Comments: 2365                          University of Oregon
BCP: 23                                                        July 1998
Category: Best Current Practice

                  Administratively Scoped IP Multicast

5. bad protocol mechanism still

   Then it sends a DAAdvert message
   with the "peering-connection-indication" attribute through this
   channel to notify the peer that this is a peering TCP connection
   (Figure 6).

   To do this, it sends a DAAdvert message with
   the "data-copy-request" attribute to the chosen peer (Figure 7).

   To keep a peering TCP
   connection alive, a mesh-enhanced DA SHOULD send a DAAdvert message
   with the "keepalive" attribute via the channel every
   CONFIG_DA_KEEPALIVE (< CONFIG_CLOSE_CONN) seconds (Figure 8).

I don't really like the use of attributes for protocol messages.  
The attribute is supposed to be an attribute of the DA not of the 
state of the connection on which the message arrived or to carry 
a request.  A better mechanism would be to add an SLP extension 
for these purposes. Another possibility would be to add two new 
SLP message types [DA Mesh Announce] which expects a SrvAck reply 
(for initiating and keeping up a mesh link) and [DA Update Request] 
which initiates a series of SrvReg messages. You can leave it as it 
is - these are just suggestions! 

6. spelling

However, for a thin-client UA implementation, it might
   deserve further considerations.
                                ^
->
consideration

7. Inaccurate:

   DAs can use standard SLPv2 DA authentication to
   authenticate other DAs in the mesh.

Actually:

DAs SHOULD use standard SLPv2 authentication before accepting 
SrvReg and SrvDereg messages.  This prevents illegitimate 
modification or elimination of legitimate service registrations.  
SLPv2 with mesh enhancements is just as secure as SLPv2.

////////////////////////////////////////////////////////////////////

Are these questions unanswered?

- Does a mesh enhanced (ME) DA forward to all DAs whether they are 
ME or not?  I think they have to or else a ME SA will forward to a 
ME DA and not the non-ME DAs and UAs won't be able to find the 
services.  
- In a deployment where multicast is not supported and DAs are 
configured using DHCP, DA options have to be included for all ME 
DAs, or DA s have to be staticly configured with the other ME DAs.  
That is because the DAs have to all know about each other.
- What is the minimum needed to do to add mesh enhancements?  
I think the answer to this is to add one or more ME DA to the 
network.  One gets immediate benefits (a) A ME SA only has to 
keep track of and register with that one DA (or rather the set 
of DAs that support its scope list).  Its registrations will be 
forwarded to all other DAs, whether mesh enhanced or not.)

////////////////////////////////////////////////////////////////////

A constants section is needed.  Example:

Mesh-Forwarding Extension Action Codes

TO_BE_FORWARDED                1
HAS_BEEN_FORWARDED             2

CONFIG_DA_KEEPALIVE            900 seconds

Mesh-Forwarding Extension ID   0x0006

////////////////////////////////////////////////////////////////////

I think a backward compatibility section would be really helpful. 

SA          Does passive      | DA       Accepts de/registrations
            DA discovery      |          normally.  These may come
            and de/registers  |          from either a SA or a ME 
            with all DAs      |          DA. Does not forward them.
            in its scope.     |          
                              |
ME SA       Will only need    | ME DA    Accepts de/registrations
            to do passive     |          from SAs and ME SAs.  If 
            DA discovery &    |          it receives a message from
            de/register w/    |          a ME SA, it will forward it
            non-ME DAs if     |          to other DAs (both ME and
            there are no ME   |          non-ME DAs).
            DAs in its scope. |

////////////////////////////////////////////////////////////////////
Additional work items:

- After you review my comments please release an -04 draft (if you 
think any changes are needed).  We can then request that the document 
be advanced to an experimental RFC.  This will mean that the IESG 
will do a review, but it is not the in-depth-review which a standards 
track advancement request would get.

- I will enhance the SLP DA service template so that it includes the
attributes which have been defined in this document.  I will send you
a copy of the modified template so you can check it.

////////////////////////////////////////////////////////////////////

The draft is in really great shape & the fact that it has been 
implemented is enough of a sanity check for a strong argument to 
move to experimental, I think.

Erik