Re: iSNS comments

[sandeepj@research.bell-labs.com (Sandeep Joshi)]

> some comments on the new iSNS draft
> 
> 1) it lacks a Table of contents, unlike iSCSI.  please add one.
>    (given that, i am liable to have missed some section which 
>     might have answered the questions raised below!)
> 
> 2) What happens if an iSNS client tries to update its 
>    TCP/UDP port or IP address (for Portal/ESI/etc) ?
>    
>    So the entry exists, and now the client sends a RegDevAttr
>    request with the update flag set for changing the above.
>    
>    If the port(s) is going to be well-known, the questions below 
>    may not arise.  If not,...
>  
>    a) Will the old TCP connection be broken by the iSNS server ?
>    b) Would the RegDevResponse be sent to the old/new port ?
>    c) Who initiates the new connection (client or server) ?
>    d) How would the client know the request succeeded ?

i see what i missed here.. SLP, which is orthogonally managing 
the "control" plane.  the questions above dont arise.

>    
> 3) Is there a requirement to provide (keyword=MUST) a secondary 
>    iSNS server ?  If I am not mistaken, DNS does mandate a  
>    secondary server for every zone to avoid single-pt-of-failure.
>   
> 
> -Sandeep