Hi Margaret, > >I think that we can discuss if we need to add any clarifying text > >here. It could be as simple as this document is informational > >and should not override any standards documents. Please note > >that many of the authors of the document are also involved in > >the 3GPP standardization process. > > It is possible that some sort of clarifying text could alleviate > some of my concerns.
That's good - our intention has never been to put anything on general IPv6 hosts, but how to ensure they would work & work effectively when connecting to cellular networks. > However, this document does seem (at least to me) to contradict > some standards-based IPv6 documents. For instance, this document > indicates that some features are optional that are listed as > mandatory in other documents (IP Security, DAD, some types of ND > processing, etc.). Let's discuss them. The authors intended to help give clues to implementors about when these functions are useful & were not. Originally, the 3GPP addressing architecture was a bit different than what was in the specs, so we were trying to bring that information out - fortunately, that specific issue has changed. > I mostly agree. I do have some concerns about defining the host > requirements too early, before we have enough deployment experience > with complete IPv6 implementations to make wise choices. This may > be a chicken and egg issue, though -- how will we get "complete" IPv6 > implementations before we define what that means? Well, this is a chicken & egg scenario. There are IPv6 implementations, of course. Most are not complete according to all of the IPv6 standards. Without creating some sort of reference document, we run the risk of creating defacto standards which are contrary to the RFCs. > I think that we should give guidance, and we have tried to do so > in other documents. However, I think that we need to be careful > not to give inconsistent or conflicting guidance. Specifically: > > - We should not publish guidance for cellular vendors > that conflicts with our published standards. > If the standards are wrong (or fail to take > into account all of the cases), we should > correct them. Agreed. > - The IPv6 WG may not be the correct group to provide > guidance regarding transition mechanisms. I > believe that the v6trans (or is it still ngtrans?) > WG should be responsible for publish advice on > the applicability of their mechanisms in > different environments. Well, NGTRANS is discussing transition (from IPv4) to IPv6. In many cases, our document is specific to v6, with no coment on v4. PILC has been doing some related work, but that WG is getting ready to close down, and has been focusing their work higher up in the stack. What I think the authors want from folks in the IPv6 wg is a reality check that what we are saying is more-or-less OK & should not cause interop problems. John -------------------------------------------------------------------- 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] --------------------------------------------------------------------
