I don't agree. But I am thinking the authors bag the IETF and take this elsewhere unless we can agree on use vs compliant systems.
/jim > -----Original Message----- > From: Tony Hain [mailto:[EMAIL PROTECTED]] > Sent: Monday, March 04, 2002 12:07 PM > To: [EMAIL PROTECTED] > Subject: Should connecting to the Internet be Optional? > Importance: High > > > Margret has raised several valuable questions about > draft-ietf-ipv6-cellular-host-00.txt, which show it is clearly is not > ready for last call. While I am willing to believe that there > are valid > reasons to make adjustments based on characteristics of the link, this > document is fundamentally flawed because it is based around > the pretense > that small footprint devices are somehow special. We MUST NOT allow > ourselves to modify well thought out architectural > fundamentals based on > point-in-time engineering constraints that are dubious at best. If a > device wants to participate as an Internet node, there are basic > requirements. Of course, participating in the Internet is optional, so > if a device would prefer to avoid the requirements, it may choose to > create its own universe. > > The argument that small devices have limited processors or memory > overlooks the fact that the processor and memory of many hand-held > devices today is significantly greater than the workstations that were > available when IPv4 was defined. Interesting point; there was > no problem > getting the stack and an array of applications to fit then. Another > interesting point; there are frequently rumors that laptops > will include > cellular interfaces, so where does the processing and memory > constraint > fit in that case? > > On the subject of applications, the absolute BS about limiting the > application set to avoid an IPsec requirement is something > that belongs > in a product development discussion, NOT a standards > discussion. The one > point that should be clear is that over time the number of > applications > used via wireless (cellular or otherwise) will grow, and that we can't > predict what they are, much less what they will need from the > stack. To > that point, we MUST reiterate that ***ALL IPv6 IMPLEMENTATIONS MUST > INCLUDE SUPPORT FOR IPSEC***. If we relax that requirement, > applications > will never be able to expect support, therefore will have to keep > inventing their own mechanisms. The only way to prevent new > applications > from appearing on computing devices is to put the executable code in > non-rewritable, non-replaceable, rom. > > If a document on cellular requirements makes any sense, it has to be > based on differences in fundamental characteristics of the > air link, not > the device on either end. Avoiding DAD simply due to expense is not a > valid justification, but if the loss characteristics of the > link make it > more problematic than valuable, there may be an argument. Keep in mind > that doing so precludes the use of RFC3041 addresses, so the > applications where anonymity is most valuable (as one moves around and > doesn't movement traced) are precluded. A non-zero probability of > collision requires a mechanism to resolve duplicates, and DAD is the > currently defined one. If another one exists that makes more > sense over > a lossy air-link, we should consider replacing DAD because it will > probably be more reliable in the general case as well. > > Tony > > > -------------------------------------------------------------------- > 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] > -------------------------------------------------------------------- > -------------------------------------------------------------------- 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] --------------------------------------------------------------------
