On Thu, 20 Mar 2003, Bound, Jim wrote: > This document started because the 3GPP vendors did not want to do all > the musts in the RFCs. Fine so lets just make this a 3GPP document > which it was in the first place.
I thought the issue was more about *WHICH* RFC's to implement, no which MUSTs (or whatever) to ignore in those RFC's they intend to implement. The same applies in node reqs, I think. > > -----Original Message----- > > From: Jari Arkko [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, March 19, 2003 12:30 PM > > To: [EMAIL PROTECTED] > > Cc: Bound, Jim; [EMAIL PROTECTED] > > Subject: Re: Mobility in Nodes Requirements > > > > > > [EMAIL PROTECTED] wrote: > > > Jim, > > > > > > > > >>>I don't believe that servers, for example, need to implement > > >>>mobile node functionality. If a node is fixed and will not > > >>>move, what use is mobile node functionality? > > >> > > >>A server in a helicopter or plane is mobile for a few > > applications. I > > >>understand I am trying to make a point that this exercise > > needs to be > > >>focused on more than the term "node". > > > > > > > > > So, perhaps I should have said 'Nodes which change their IP > > addresses, > > > for example base on Mobile IP, MUST implement mobile node > > > functionality.' > > > > > > Would that kind of text cover your needs. > > > > This is a circular definition. The issue is that a node might > > not know whether its attachment to a network is going to > > change or not. Those that get these changes, could use mobile > > IPv6 to deal with it and still keep sessions flowing. > > > > Jim may have a point here about the server in a helicopter. > > But where do we draw the limit? How do we know that 3000 kg > > IBM mainframe isn't being flown around in a cargo aircraft? > > Also, the type of the interface on the device may have > > significance. Or the application; a sensor reporting its > > findings using a single packet would not need mobility. > > > > In conclusion I don't think we can base the mobile node > > support requirement on the above definition. The options that > > I see are the following: > > > > - "Hosts MAY/SHOULD/MUST support mobile node functionality" (the > > current text uses MAY). > > > > - "Hosts SHOULD/MUST support mobile node functionality <condition>". > > > > Here <condition> could be e.g. related to the > > type of the device "on portable devices", or maybe "on devices > > weighing under 2 kilograms" ;-) > > > > We could base it on the type of the interfaces supported, > > e.g., "on devices that may use wireless interfaces", > > > > We could base it on the type of the application, e.g., "on > > devices that may have applications that require sessions to > > survive movements". > > > > Frankly, I'm not sure it is possible to formulate a good > > condition for the second option. So I'm inclined to think > > that its either the current MAY support or possibly SHOULD > > support. What do people think? > > > > >>>>> Hosts SHOULD support route optimization requirements for > > >>>>> correspondent nodes. Routers do not need to support route > > >>>>> optimization. > > >>>>> > > >>>>> Routers MAY support home agent functionality. > > >>>> > > >>>>Routers SHOULD support the HA is correct effort. Otherwise MIPv6 > > >>>>don't work. > > >>> > > >>>Not all routers need to be Home Agents I don't believe that > > >>>plain, vanilla routers will be affected by home agent > > functionality. > > >> > > >>Routers that implement MIPv6 SHOULD support HAs. Again context is > > >>everything. > > > > > > > > > That text works for me. > > > > Uh... that's also a circular definition. Like Pekka noted > > already, there are two pieces of router functionality > > (sections 8.3 and 8.4). The current keywords are SHOULD for > > the AI option etc and MAY for the HA functionality. We can > > debate these keywords, but I personally think they are fairly > > close to the right thing. > > > > Jari > > > > > > -------------------------------------------------------------------- > 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] > -------------------------------------------------------------------- > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- 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] --------------------------------------------------------------------
