[EMAIL PROTECTED] wrote: > ... > Our intention is to write this specification as "minimum > IPv6 functionality for a cellular host", i.e. not defining > any kind of 'maximum set of functionality'. > ... > As a summary, a cellular host (often) has limited size, > memory, processor capacity and battery capacity / power > consumption. The users would like to see their terminals to > be usable for quite a long time (typically for some days, at > least stand-by time) without re-charging them.
You are focused on the engineering constraints of a particular device (host) that is *only useful* in a cellular context as the definition. My point was that there are many other devices that could take advantage of the cellular link technology, and therefore MUST be considered 'cellular hosts'. Statements in the document like: 'A cellular host SHOULD NOT perform Duplicate Address Detection ...' or lack of support for IPsec that is justified as too hard for a small device to implement are focused on engineering issues for a particular product, not the architectural minimum. If there are characteristics of the cellular link that make the current standards inappropriate as written, we should address those. If you are looking for concessions simply for marketing reasons related to a particular target product, this document should die right here. The statement 'We can not list all possible services here, and in general we expect application protocol RFCs to have requirements on what security services they MUST employ.' is both an unrealistic expectation, and the fundamental reason that we are being so insistent about the requirement for IPsec. As a general rule, we don't expect (or have the means to require) that every application define security requirements; and even if they did evolving the security infrastructure to meet the needs of every new application would be insane. On the other hand by providing a secure channel for use by any application we can build an infrastructure that scales. The argument that a cellular host is exempt only ensures that the application developer can't count on that secure channel being available, so each one has to do something specific to address their needs. If you want to do as Keith suggested and split off fixed-function as a special case, I won't object too loudly. Even there you preclude something like a Java app, that comes in over the TLS channel, from opening a non-TLS secure channel to get additional content. Yes it is a fixed function web-browser, but do you really know how every web site is designed, and can you ensure that all bits in and out of the device can be protected by TLS? 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] --------------------------------------------------------------------
