RE: zeroconf draft

["Soininen Jonne (Nokia-NET/Helsinki)" <jonne.soininen@nokia.com>]

On Tue, 2004-08-24 at 11:04, ext Pekka Savola wrote:
> On Tue, 24 Aug 2004, Soininen Jonne (Nokia-NET/Helsinki) wrote:
> > > Initially, it was thought that 3GPP scenarios would have been suitably
> > > addressed by the simple mode of the assisted tunneling, but you guys
> > > felt it was better to have a separate document; that's fine, it seems
> > > to me that such a document should include all the related, similar
> > > scenarios.
> > 
> > This, of course, has been a sticky point from the beginning. There seems
> > to be two schools of thought: One saying that assisted tunneling's
> > simple mode would fit the 3GPP scenarios. The other is saying that
> > assisted simple mode does not fit the requirements of 3GPP. Thus, an
> > additional document was decided to be created to see if the requirements
> > are the same instead of artificially putting the two possibly
> > distinguished set of requirements into the same document.
> > 
> > I believe if the scope is kept well and not bloating the document with
> > non related requirements we can do the analysis of the two set of
> > requirements and see of the two sets are equal. 
> > 
> > So, from my perspective I think it is important that the scope of the
> > document is kept narrow instead of over widening it. 
> 
> It doesn't seem useful to argue this point, so I'll just note that
> I'll disagree with this approach because I don't think the
> requirements actually are all that different.  The biggest difference
> comes from the no-NAT assumption and the rest should be about the
> same.

I hope we will be able to compare the two finished set of requirements
very soon! ;)

> 
> > > I'm not sure which words to use to describe this situation, but I 
> > > personally feel it's pretty important, because this could set very 
> > > tight requirements on the applications folks may wish to deploy now or 
> > > later, or deployments in more general.  
> > 
> > Are you saying that everything that is supported by native v6 (e.g.
> > multicast) must be supported by the tunneling mechanism, or are you
> > stating that if something is not required it should be explicitly
> > documented? 
> 
> It's up to the requirements of the scenarios to decide that :-).
> 
> The document could for example list examples of mechanisms/protocols
> which do not need to be supported, or require that all should be
> supported.  It depends on the scenario and conceived application
> usage, both now and in future.  The key point in my comment is that it
> needs to be very clearly stated if it's OK that certain v6 mechanisms
> or protocols (such as DHCPv6, multicast, SEND, etc.) do not need to
> work.

Fair enough. Thus, if something does not need to work it has to be
documented. I guess, I agree with that.

> 
> > If the terminal has to keep the tunnel alive, would it mean that it
> > has to wake up the radio periodically (even when it would not need
> > it otherwise) send a packet over the radio and possibly wait for
> > answer. This means that it cannot be in a "dormant" mode all the
> > time it's idle. This consumes battery quite a bit. In addition, it
> > reserves radio resources for the sending of the keep-alive
> > unnecessarily.
> 
> You mention good points and these should probably go in the draft in 
> some form, as clarifying material.

I guess, Karen can see if there is a place in the document where this
can be documented.

> 
> (I certainly can't think of any protocol on the table which would 
> *require* such keep-alives when there are no NATs to cross, but it's 
> still good to have that goal specified.)
> 
> > > This is already discussed in another thread, but I think the key point
> > > here is *node-to-node* communication, not direct tunneling as such.
> > 
> > Maybe I'll find the definition in the other thread, but I don't really
> > understand what is node-to-node communication in the sense you put it
> > here. I guess, IP is all about node-to-node communication.
> 
> I was using "node-to-node" communication as a shorthand for something
> like "node-to-node communication inside the direct tunneling range",
> i.e., local communication between nodes which could be directly
> tunneled if the protocol supported it.

Ok. 

Cheers,

Jonne.

-- 
Jonne Soininen
Nokia

Tel: +358 40 527 46 34
E-mail: jonne.soininen@nokia.com