Subject: RE: WG LAST CALL: draft-ietf-zeroconf-reqts-05.txt

From: "Nicolae, Dan" <[email-masked]>
Date: Tue, 03 Oct 2000 17:45:34 -0400

A few comments/questions on 05:

I. 
   "... The requirement is the 
   protocol MUST be routable. For example, a protocol MUST use IP 
   multicast and not use IP broadcast. 
    
   Requirement: 
   - If a protocol is to operate in multiple IP subnet topologies, 
     the protocol MUST be routable."

Is this requirement really needed? What's its value besides disqualifying
broadcast-based protocols (as the example states)?
Can we talk about protocols operating above the network layer as being
routable or not? IP is routable so anything that runs over IP is routable.
The fact that packets sent to certain IP addresses MAY be discarded by a
router does not make a protocol less routable.

I don't want to get tangled in a terminology issue, but the requirement
sounds a bit confusing to me. I would favor removing the whole section 1.5.

II.
   "Topology changes may create any of the following problems: 
   conflict among netmasks, conflict among default routes, duplicate 
   IP addresses within an IP subnet, or duplicate IP subnets within 
   an internet. Note that default routes and duplicate IP subnets are 
   not issues for single IP subnet networks."

Could we remove "conflict among netmasks"? Isn't this the same as a subnet
address conflict?
Also, I do not understand what "conflict among default routes" means.

III.

   "Requirement: 
   - MUST allow a host to determine if it has a unique name.  
   - MUST be able to determine if subsequently chosen names are 
     unique, if the first name is not. 
   - If a domain name and host name exist as separate configuration 
     parameters, additional checks for uniqueness SHOULD be 
     performed on the combined host name and domain name."

I think that the first requirement covers the next two as well.

IV.

   "Printers vary in their characteristics such as location, status, 
   dots per inch, drivers, etc. Discovering these characteristics 
   SHOULD be part of the service discovery protocol. Alternatively, 
   the client and server MAY negotiate the use of these 
   characteristics after the service is found."

- Not the characteristics are discovered, but services with those
characteristics
- The SHOULD and MAY seem contradictory. Is attribute-based discovery purely
optional or not?
- Once a service is found no negotiation is needed. Further selection based
on specific attributes is not part of discovery (or is it?).

My opinion:
   Printers vary in their characteristics such as location, status, 
   dots per inch, drivers, etc. 
   Discovering based on these particular characteristics 
   SHOULD (or MAY?) be part of the service discovery protocol.  

V.
   "Discovery SHOULD be possible by either the client actively 
   soliciting the service or by the service advertising then the 
   client passively listening for the advertisements. At least one 
   method MUST be available. Once a client finds the printer, it can 
   utilize different printing protocols such as raw tcp, lpd, and 
   ipp."  

I believe the SHOULD needs a "both" instead of "either". That would make it
consistent with the (correct)requirement at the end of section 2.4.1:
   - MUST allow discovery by client actively soliciting the service 
     or by the client passively listening for advertisements. Both 
     methods SHOULD be available. 

Also, what is the purpose of "once a client finds the printer, it can
utilize different printing protocols such as raw tcp, lpd, and ipp"? It
seems irrelevant to the topic.

VI.

   "- SHOULD discover via characteristics or negotiate 
     characteristics."

I would say to remove "or negotiate characteristics" (see IV).

VII.

   "In the case of a printer service, a printer may be temporarily 
   taken off-line for repair or everyday maintenance. This requires 
   clients to be able to rediscover a service." 
    
   "- MUST allow clients to rediscover a service."

I do not understand the difference between "discover" and "rediscover". Is
this requirement needed?

VIII.
Not a big deal, but I prefer "Printer Discovery Proxy" instead of "Printer
Manager".

IX.
The whole section 2.4.2 seems a bit unclear to me.
We start by talking about a print manager that is a discovery proxy and end
up with requirements about registries. What is the connection between the
two? Who is the proxy, the print manager or the registry?
Could we give some clarifying examples here?

/dn

> -----Original Message-----
> From: Erik Guttman [mailto:[email-masked]]
> Sent: Monday, September 25, 2000 3:33 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Subject: WG LAST CALL: draft-ietf-zeroconf-reqts-05.txt
> 
> 
> This is a notice of a Working Group Last Call on the document
> 
>   http://www.ietf.org/internet-drafts/draft-ietf-zeroconf-reqts-05.txt
> 
> Please send your comments in the next two weeks.  At that time 
> (October 9) we will evaluate the working group consensus on the 
> document, if necessary revise the document, then submit it to the 
> IESG for publication as an Informational RFC.
> 
> Erik
> 
> 
> 
> 
>

---

From: Erik Guttman <[email-masked]>
Date: Wed, 4 Oct 2000 13:00:15 +0200 (MET DST)

On the whole I agree with your comments.  I just wanted to reply to/
expand on a couple points you made.

> broadcast-based protocols (as the example states)?

There are two categories of protocol this requirement was meant to address:
Broadcast-based protocols and 'link-local' protocols.  What we're really
trying to say is that these protocols are inappropriate if we want more
than link-local operation.  Maybe the text isn't clear here.

> - Not the characteristics are discovered, but services with those

Agreed.  But this could be done either on the server-side (by processing
a client's service request) or on the client-side by retreiving the service
attributes and deciding the client's suitability there.  The former strategy
is used by SLP, the latter, for example, by Microsoft's SSDP.  SLP does not
require transmission of service information that the client doesn't want, 
where SSDP does.

> - The SHOULD and MAY seem contradictory. Is attribute-based discovery purely

The SHOULD refers to attribute based discovery.  The MAY to feature 
negociation after discovery is over, between the client and server.
If you have 'ideal' service discovery, you don't need feature negociation
since the client will discover the server which has all the features it
needs and the protocol configuration to use so that the server will know
just how to communicate with the client.  In some cases service discovery
won't be ideal though.  The client may discover the appropriate server but
still need to inform the server of client features so that a proper inter-
action can result.

> seems irrelevant to the topic.

The only important thing is that after service discovery is over the
client can use the server.  That means that the client needs to know
what protocol to use.
 
Erik