Subject: RE: Mobility in Nodes Requirements

From: "Bound, Jim" <[email-masked]>
Date: Thu, 20 Mar 2003 17:47:35 -0500

Jari,

THen go fix 2119.  I am basing my comments on that RFC.

Thanks
/jim

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Wednesday, March 19, 2003 11:57 AM
> To: Pekka Savola
> Cc: Bound, Jim; [email-masked]; [email-masked]
> Subject: Re: Mobility in Nodes Requirements
> 
> 
> 
> Pekka Savola wrote:
> 
> >>Routers that implement MIPv6 SHOULD support HAs.  Again context is 
> >>everything.
> > 
> > 
> > There requirement:
> > 
> >   Routers SHOULD support the requirements set for all IPv6 routers.
> > 
> > basically only means the support of new RA intervals and such 
> > "trivial"
> > changes -- which enable smoother first-hop-router to 
> > MN's-in-foreign-networks scenario.  Requiring HA is 
> entirely different 
> > issue.
> 
> This is correct. There are indeed two issues, see Sections 
> 8.3 and 8.4 in the mobile ipv6 specification.
> 
> As to the requirement to support HAs in all routers... I 
> don't have a strong opinion but I kind of like the MAY. This 
> is because I usually prefer features selling themselves for 
> their benefits, rather than due to them being mandatory in 
> some standard...
> 
> 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-masked]
--------------------------------------------------------------------

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 20 Mar 2003 17:46:43 -0500

John,

That would work.  But I am already working on my IESG appeal and case
for stateful so go for it.  I will state my case to the IESG once it is
done with Last Call as appeal when/if it is done.

Thanks
/jim

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Wednesday, March 19, 2003 11:41 AM
> To: Bound, Jim; [email-masked]
> Subject: RE: Mobility in Nodes Requirements 
> 
> 
> 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.
> 
> > > > >    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.
> > 
> That text works for me.
> John

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 20 Mar 2003 21:08:59 -0500

Not clear what the goal is.  But am clear what made it happen and that
was 3GPP.
/jim

> From: Pekka Savola [mailto:[email-masked]] 
> Sent: Thursday, March 20, 2003 5:56 PM
> To: Bound, Jim
> Cc: Jari Arkko; [email-masked]; [email-masked]
> 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.
> 
> > > Sent: Wednesday, March 19, 2003 12:30 PM
> > > To: [email-masked]
> > > Cc: Bound, Jim; [email-masked]
> > > [email-masked] wrote:
> > > > Jim,
> > > > 
> > > > 
> > > >>>mobile node functionality.  If a node is fixed and 
> will not move, 
> > > >>>what use is mobile node functionality?
> > > >>
> > > addresses,
> > > > for example base on Mobile IP, MUST implement mobile node
> > > > functionality.'
> > > > 
> > > 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?
> > > 
> > > >>>>Routers SHOULD support the HA is correct effort.  Otherwise 
> > > >>>>MIPv6
> > > >>>>don't work.
> > > >>>
> > > 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
> > > 
> > > 
> > 
> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> 
>

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 20 Mar 2003 21:10:04 -0500

It is only for BCP.  Not PS.  I just found that out this week per my
last mail.
/jim

> Sent: Thursday, March 20, 2003 6:28 PM
> To: Tim Hartrick
> Cc: [email-masked]; Bound, Jim; [email-masked]
> On Thu, 20 Mar 2003, Tim Hartrick wrote:
> > In general, I agree with Jim here.  I have never seen the 
> need for an 
> > IPv6 node requirements specification.  The need for the IPv4 host 
> > requirements document was in large part driven by the large 
> number of 
> > ambiguities and bugs in the original IPv4 RFCs.  [...]
> 
> I agree, at least to a degree: I believe the optimal category 
> should be BCP or Informational.  PS (as is currently in the 
> charter) is also fine, though I see little which would 
> require this -- and in fact might give a wrong picture of the 
> nature of the memo.
> 
> But this is a discussion we probably have had many times -- 
> too bad I just 
> remember the outcome and justifications (well, one: IPv4 
> NodeReqs was PS 
> for reasons given by Tim).
> 
> --

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 20 Mar 2003 21:07:51 -0500

Correct.  Also as a note solving an engineering problem for the non
typical user can result in more profit than the typical, and why it does
interest me.

But I see your point.

For some reason I thought this doc was a standards track its not.  Its
BCP.

So now I care less from an appeal perspective.

But I still think stateful is a SHOULD just like I thought sitelocal was
not needed 5 years ago and DHCPv6 was needed and many did not want that
to happen either.  They learned.  The market will decide at the end of
the day.  Stateful will be used initially more than statless except for
handhelds and roaming devices and for stateless ad hoc deployment
architectures which I admit is the majority of what I am working on now
in the IPv6 user community.  Stateless has new "operational" advantage
IPv4 does not.  Ergo a lot of people are chomping on the bit to use it.
And to a point where you and I to not agree again.  Those people are
going to move to IPv6 far faster than we think here.  They will build
immediate IPv6 Intranet or Private-Internet IPv6 backbones.  And they
want DSTM :---).  But we will do it for them out of here don't worry
:--)

/jim

Thanks
/jim

> Sent: Thursday, March 20, 2003 5:53 PM
> To: Bound, Jim
> Cc: [email-masked]; [email-masked]
> > > Such is hardly a minimal or even typical case of IPv6.
> > 
> > So you only want to work on the typical case in the IETF?
> > 
> > It appears you do not care about the non typical?
> 
> No, but we certainly *must* consider what's typical when setting 
> *requirements* for *all* nodes.
> 
> Non-typical cases are fine -- and will be used, that's great, 
> the more IPv6 the better -- but I don't see why such should 
> set what the mainline does.
> 
> I can easily envision server on a helicopter.  That's a case, 
> of course.  
> But something that must be taken into consideration when 
> implementing the helicopter and the server.
> 
> --

---

From: [email-masked]
Date: Sun, 23 Mar 2003 07:05:15 +0200

Praveen,

> Should the draft stick to only those reqirements that are 
> essential and steer clear of the others ?? After all it might be 
> tough to capture all optional features in the draft.

I think that the draft should capture most all of the basic
IPv6 RFCs at the level needed.  For some, sub-requirements
may need to be explicitly called out, while for others,
simple level of support needed may be enough.

John

---

From: "Bound, Jim" <[email-masked]>
Date: Wed, 26 Mar 2003 21:04:43 -0500

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

>Sent: Tuesday, March 25, 2003 4:19 PM
>To: Bound, Jim
>Cc: Kurt Erik Lindqvist; [email-masked]
>(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
>
>
>