> FWIW, I fully support Thomas Narten on his view that MIPv6 should not be > making all of these assumptions to e.g. Neighbor Discovery timer values.
I think this makes sense as well. Let me try to state my reasons. Even though I think the current ND changes in the MIPv6 spec make sense, I'm concerned that implementors for IPv6 routers, which don't otherwise implement MIPv6, will find these pieces deep inside the MIPv6 specification. I think these things are more likely to be widely implemented if they live in a separate and shorter RFC. Also, we are likely to discover additional optimizations that might help with mobility and having a set of small specific extensions and/or modifications around ND or other protocols seems like a quicker way to make progress on these things. So while I don't want to slow down the MIPv6 specification or the implementation and deployment, I think breaking out these pieces will help with specification and protocol modularity, which makes it easier and quicker to revise the specifications along the standards track etc. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
