Jari, This is all a moot point and discussion for me. Its informational. I will not support it in the industry as one individual (not speaking for my company). I will suggest it be used as guideline.
That being said my point was missed and I don't see the point of fighting it for an Informational RFC that is questionable at best with its purpose. My point is there should be docs for 3gpp, Providers, Enterprises, et al. This is an attempt to appease different factions in the IETF that have an agenda in the market. I will not be part of it or support out of the IETF. Except as guideline that some good "technical" engineers like John, Jonne, et al took the time to work on and that part makes it possibly useful. I have no more to say on this issue. IF we meet in the market and debate be prepared to hear more, and I will be armed with what I would have used to appeal any IESG decision for proposed standard. This is plain wrong. But that is fine we all loose battles. But I will not give in and say it was right. How about NO. Regards, /jim >-----Original Message----- >From: Jari Arkko [mailto:[EMAIL PROTECTED] >Sent: Tuesday, March 25, 2003 4:19 PM >To: Bound, Jim >Cc: Kurt Erik Lindqvist; [EMAIL PROTECTED] >Subject: Re: Mobility in Nodes Requirements > > > >(Sorry for not getting back to this issue sooner, but I just >got home after some touring at Tahoe and lengthy flights home.) > >> This is my exact point about this spec. >> >> It seems if this will continue without a focus as Kurtis says below >> and I have stated previously we will need a serious applicability >> statement. >> >> Because it is BCP I am backing off a little as most of the market >> don't care about our BCPs. But there needs to be applicability >> statement. > >Jim, > >Charter says Informational and I believe that is could be >acceptable to you as well? > >If by "without a focus" you mean that we are not describing >the requirements for IPv6-enabled servers flying in >helichopters, then I agree. That is, we do not describe what >IPv6 features should be used in specific applications. And >yes, there should be an applicability statement to this >effect. Perhaps you'd be willing to submit some text? > >However, I still feel strongly that we MUST describe what >"components" IPv6 has and what their mandatory/optional status >is. Not the need in a specific application, but whether >something is *always* needed. And a directory of optional >components. (In some specific subset of cases we can also give >a rule when the optional component becomes >mandatory.) > >I believe this is very useful for ensuring the >interoperability and success of IPv6, and I'm a bit surprised >that you seem to disagree. I've heard a number of counter >arguments to this kind of specifications and I would like to >take this opportunity to discuss them: > >* "Its obvious". Right. So why we are debating the > keywords for DHCP and MIPv6...? > >* "Its in the other RFCs already". Probably so, at least in > some cases. If you dig up the information by reading all > RFCs, that is. And I know for a fact that some specifications > explicitly left the decision out; at least MIPv6 does > this in expectation of IPv6 saying something about it its > specifications. > >* "We can't agree anyway what the mandatory components are". So, > we shift our problem to the customers and end-users? No, let > the buck stop here. Not in IESG, vendors, or customers. > >* "All this depends on the applications." Some things depend > on the applications. But not all. And even if some things > are needed on a per application basis, wouldn't it be useful > to document that so that no one mistakes something for > mandatory? > >* "Market place decides anyway." Yeah. But in my experience > the rules in IETF specifications still have a lot of > weight. > >* "The set of requirements for any specific application > is going to be much different or more extensive than > this". I agree. But no one claimed this was all you > had to do to protect the flying servers. > >* "Maybe you can list the mandatory components, but I don't > see a need to look at the optional ones." Well, how do I > know that if RFC nnnn isn't listed, its (a) optional or (b) > forgotten? I say we should be explicit and list the optional > components too. > >* "Early IPv4 RFCs were so bad that we needed a lot of explanations, > but it doesn't apply to IPv6 anymore". I agree, but if you look > at the node requirements document, it doesn't follow the IPv4 > host requirements style at all. We only list specific RFCs. > There's a small number of cases where large RFCs contain a number > of independent pieces (such as MIPv6) that we have also listed. > But I agree, we shouldn't be explaining and patching existing > RFCs. Fortunately, we are not doing that. > >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] --------------------------------------------------------------------
