Re: Comments on zeroconf draft

[Radhakrishnan Suryanarayanan <rkrishnan.s@samsung.com>]

Hi Karen,
> > > - plus keep alive messages
> >
> > .. which the client may choose not to send.
>
> Yes, but, quote:
> "but [the client] should then expect that the tunnel may be
>    disconnected at any time by the ISP and be prepared to restart the
>    set-up phase"
I dont think its hard to convince the authors of assisted tunneling draft to
change the "SHOULD to "MAY". In 3GPP networks, the ISP can always switch off
the keepalive messages & then
 the question of tearing down of a tunnel from ISP might not as well happen
at all.

> >
> > > - plus IPv6 dns registration by server side
> >
> > .. which is practically an implementation issue at the server side,
> > because the protocol is explicitly not required to support this.
> >
>
> Yes, that is what is being said (:-) But if you think about it
> this puts requirements on the tunnel protocol.
> As a minimum the server must be able to ascertain when a certain node
> (identified by something - the IPv4-address ?) is reachable and
> not-reachable at a certain IPv6-address.

IMHO, this is not a problem. Please see the quote below
" If stable prefix delegation is done, it is expected that the DNS
   delegation of the associated reverse DNS zone will be also stable and
   thus can be performed out of band, so there is no requirement to
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   perform this delegation at the tunnel set-up time."
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^


> The authors of assisted-tunnelling have only thought about stateful
> mechs, I think.
Have the authors of zeroconf requirements have any stateless mech in mind?
I feel that  every tunnel server WILL have to maintain a min. set of client
parameters implicitly making it stateful.