Subject: RE: Mobility in Nodes Requirements

From: "Bound, Jim" <[email-masked]>
Date: Mon, 24 Mar 2003 01:04:45 -0500

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

>-----Original Message-----
>From: Kurt Erik Lindqvist [mailto:[email-masked]] 
>Sent: Friday, March 21, 2003 11:24 PM
>To: Jari Arkko
>Cc: [email-masked]; Bound, Jim; [email-masked]
>Subject: Re: Mobility in Nodes Requirements
>
>
>> 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.
>
>I have the feeling that are trying to match a solution to a number of 
>problems, rather than to match a number of problems to a solution. 
>Mobility will give you <...>, and problems that match this can 
>use this 
>approach. Problems that do not needs to come up with something else.
>
>Is the space shuttle a mobile node?
>
>- kurtis -
>
>

--------------------------------------------------------------------
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: Jari Arkko <[email-masked]>
Date: Tue, 25 Mar 2003 23:18:32 +0200

(Sorry for not getting back to this issue sooner, but I just
got home after some touring at Tahoe and lengthy flights home.)

> 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

---

From: Shannon -jj Behrens <[email-masked]>
Date: Wed, 26 Mar 2003 07:54:17 -0800

On Tue, Mar 25, 2003 at 11:18:32PM +0200, Jari Arkko wrote:
<snip>
>   forgotten? I say we should be explicit and list the optional
</snip>

This is an interesting point.  However, this begs the question of what to do 
when this document grows stale.  Naturally, it will be tedious to update it 
with every new RFC.  This is probably exacerbated by the fact that the list
of optional RFC's will probably grow a lot faster than the list of required
RFC's.  If this document only listed required RFC's, it would probably be more
stable and helpful in the long run.  Hence, to answer your question:

>   Well, how do I
>   forgotten?

The answer would always be "optional".

Best Regards,
-jj

-- 
Hacker is to software engineer as 
Climbing Mt. Everest is to building a Denny's there.
--------------------------------------------------------------------
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]
--------------------------------------------------------------------