Subject: RE: Should connecting to the Internet be Optional?

From: "Karim El-Malki (ERA)" <[email-masked]>
Date: Mon, 4 Mar 2002 18:45:30 +0100

> A non-zero probability of
 > collision requires a mechanism to resolve duplicates, and DAD is the
 > currently defined one. If another one exists that makes more 
 > sense over
 > a lossy air-link, we should consider replacing DAD because it will
 > probably be more reliable in the general case as well.

No need to replace DAD but just allow it to be disabled on some links.
The previous discussion with Francis seemed to point to the issue
that PPP links where some form of prefix delegation occurs can do
without DADs. As commented already, RFC3041 would work.

Regards,
/Karim
--------------------------------------------------------------------
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: Phil Roberts <[email-masked]>
Date: Mon, 4 Mar 2002 14:28:50 -0500

Having read through this thread now, might it be better to
recast this document more along the lines of functions
supported on the cellular interface rather than requirements
for host?  Some substantial number of devices for which this
is targeted will be dual network interface capable and for the
other interface some of these optimizations don't make sense.

The Mobile IPv6 related specifications for the time being
only make sense with such a dual network interface capable
device, which means the optimizations recommended on the cell
facing interface in many cases SHOULDN'T be recommended on
the other interfaces.

> -----Original Message-----
> From: Tony Hain [mailto:[email-masked]] 
> Sent: Monday, March 04, 2002 12:07 PM
> To: [email-masked]
> Subject: Should connecting to the Internet be Optional?
> Importance: High
> 
> 
> Margret has raised several valuable questions about 
> draft-ietf-ipv6-cellular-host-00.txt, which show it is 
> clearly is not ready for last call. While I am willing to 
> believe that there are valid reasons to make adjustments 
> based on characteristics of the link, this document is 
> fundamentally flawed because it is based around the pretense 
> that small footprint devices are somehow special. We MUST NOT 
> allow ourselves to modify well thought out architectural 
> fundamentals based on point-in-time engineering constraints 
> that are dubious at best. If a device wants to participate as 
> an Internet node, there are basic requirements. Of course, 
> participating in the Internet is optional, so if a device 
> would prefer to avoid the requirements, it may choose to 
> create its own universe.
> 
> The argument that small devices have limited processors or 
> memory overlooks the fact that the processor and memory of 
> many hand-held devices today is significantly greater than 
> the workstations that were available when IPv4 was defined. 
> Interesting point; there was no problem getting the stack and 
> an array of applications to fit then. Another interesting 
> point; there are frequently rumors that laptops will include 
> cellular interfaces, so where does the processing and memory 
> constraint fit in that case?
> 
> On the subject of applications, the absolute BS about 
> limiting the application set to avoid an IPsec requirement is 
> something that belongs in a product development discussion, 
> NOT a standards discussion. The one point that should be 
> clear is that over time the number of applications used via 
> wireless (cellular or otherwise) will grow, and that we can't 
> predict what they are, much less what they will need from the 
> stack. To that point, we MUST reiterate that ***ALL IPv6 
> IMPLEMENTATIONS MUST INCLUDE SUPPORT FOR IPSEC***. If we 
> relax that requirement, applications will never be able to 
> expect support, therefore will have to keep inventing their 
> own mechanisms. The only way to prevent new applications from 
> appearing on computing devices is to put the executable code 
> in non-rewritable, non-replaceable, rom.
> 
> If a document on cellular requirements makes any sense, it 
> has to be based on differences in fundamental characteristics 
> of the air link, not the device on either end. Avoiding DAD 
> simply due to expense is not a valid justification, but if 
> the loss characteristics of the link make it more problematic 
> than valuable, there may be an argument. Keep in mind that 
> doing so precludes the use of RFC3041 addresses, so the 
> applications where anonymity is most valuable (as one moves 
> around and doesn't movement traced) are precluded. A non-zero 
> probability of collision requires a mechanism to resolve 
> duplicates, and DAD is the currently defined one. If another 
> one exists that makes more sense over a lossy air-link, we 
> should consider replacing DAD because it will probably be 
> more reliable in the general case as well.
> 
> Tony
> 
>

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Mon, 4 Mar 2002 20:34:40 +0100

> => That's a bit inaccurate, there is a major difference
  > > that is due to the BW contraints of the air link.
  > > I see your points about size and memory, but it would
  > > be good if we identify the parts related to size
  > > and memory in which the draft deviates from IPv6
  > > standards and distinguish them from the BW and
  > > l2-specific impacts.
  > 
  > Let's not go there. Those of us with lots of grey recall 
  > the days when
  > half the 3G bandwidth cost in the 6 figure range a month, 
  > with loss and
  > latencies were about the same as the 3G link. Yes it is a 
  > constrained
  > environment relative to other options today, but there is nothing
  > inherent in the BW, loss, latency, cost that limits the 
  > potential for
  > use as a packet network. While we can't assume that everything is
  > reasonable in the constrained environment, we also 
  > shouldn't be throwing
  > out capabilities that history has proven useful simply 
  > because they are
  > hard or cost a little more.

=> OK, there is no point in arguing this particular
point without pointing out the relevant parts
of the draft. After all we want to get feedback
that will improve the quality of the draft. 

  > Product decisions beyond what is technically possible don't 
  > belong in
  > the discussion about standards. My son's 3-year old 
  > calculator has more
  > low-power CPU & memory than the SGI workstation I had 10 
  > years ago, and
  > it would fit in a package small enough for a 3G handset (and has a
  > longer battery life than my phone). I have to believe that there are
  > better options out there now (at least 5 years after that 
  > device design
  > was done), so the fact that a product team doesn't want to 
  > use those for
  > a specific market is not a problem for the IETF.

=> OK, same comment as above. 

  > > Again, to be able to improve the quality of the
  > > draft, we need to point out *exactly* where
  > > the relevant problems are. Margaret did some
  > > of this already and it is being discussed.
  > 
  > I only had time for a quick pass this morning, and don't 
  > expect to get
  > much more this month. Not that my personal time should drive a WG
  > schedule, but if Margret raised several questions, and my quick pass
  > found fundamental issues, I would argue that this doc is 
  > not even close
  > to ready for last call.

=> Maragret's comments are being discussed and 
we should definitely discuss your concerns as 
well. But my point is, if the draft is not 
ready we need some concrete reasons to be able to
improve it. 
Experience also shows that ignoring 
other organisations' reasons or business models
will not help in developing the Internet that 
we'd like to see. I'm not suggesting that you're
ignoring it, but I want to highlight the importance
of participating in the work.

  > 
  > >
  > > => The document does NOT avoid DAD. The document
  > > is aimed at a generic cellular host, and wherever
  > > applicable, makes an applicability statement on the
  > > 3GPP-specific cases. The reason DAD is not needed
  > > in 3GPP, is that the way an address is allocated
  > > leaves no room for on-link duplication. And still,
  > > the document does not say, you MUST NOT do DAD,
  > > it simply says that in *this* instance of a cellular
  > > network, DAD is not needed. So if you just want
  > > to implement it anyway, then go ahead.
  > 
  > 'A cellular host SHOULD NOT perform Duplicate Address Detection...'
  > While that is not a MUST NOT, it is a very strong 
  > instruction to avoid
  > it. If it said something like 'A cellular host MAY choose 
  > NOT perform
  > Duplicate Address Detection when it has other means to ensure
  > uniqueness...' I would be less concerned.

=> You're quoting a section written specifically
for _3GPP_cellular_hosts. As I tried to explain
in *this* particular cellular network DAD is 
not useful at all, it just wastes BW. But this 
statement was not made for *all* cellular hosts.

  > >   > Keep in mind
  > >   > that doing so precludes the use of RFC3041 addresses, so the
  > >   > around and
  > >   > doesn't movement traced) are precluded.
  > >
  > > => This is not a problem and address privacy is already
  > > supported without the need for DAD.
  > > The 3gpp-advice draft, the cellular host draft
  > > and 3GPP TS 23.060 can provide the exact details.
  > 
  > If there is something specific that makes the statement 
  > true, it should
  > be written here so people don't have to chase around to find it. 

=> Appendix B of the draft explains this, and so
does the advice draft.

The
  > only thing that might make it true is that the router 
  > interface on the
  > subnet will ALWAYS have the 'unique bit' set in an EUI-64 derived
  > address, and will never use another format. This also 
  > presumes that the
  > handset doesn't provide layer-2 bridging services to other locally
  > connected devices. If it does that then there is no 
  > guarantee that some
  > device on the allocated subnet will not collide.

=> Well, bridging is not the only/best way of 
connecting other devices to the cellular network. 
The mobile terminal can also be a router or an 
MLSN. 
Bridging will introduce a lot of other complexities 
in the current 3GPP architecture. If you're interested
we can discuss it offline because it's very specific
and will probably bore everyone else.

  > >   > currently defined one. If another one exists that makes
  > >   > more sense over
  > > => It doesn't make sense if a host gets a /64
  > > prefix that can not be used by anyone else on
  > > the cellular interface.
  > 
  > See previous comment about L2 bridging by the 
  > handset/embedded device in
  > a laptop ...

=> I don't know why you need it if you 
have the /64. But anyway if you want bridging 
it can work when simply running a PPP link
between the phone and other devices behind it. 

Hesham

---

From: Phil Roberts <[email-masked]>
Date: Mon, 4 Mar 2002 14:54:56 -0500

Well, this needs to be spelled out in some detail then.  I'm already
mentally thinking of PocketPC kinds of devices whenever I here
cellular hosts....

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Monday, March 04, 2002 2:55 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: Should connecting to the Internet be Optional? 
> 
> 
> 
>  Hi!
> 
> Just commenting the possible differences between laptops and 
> cellular terminals...
> 
> There are different kinds of laptops and also different kinds 
> of cellular hosts. 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'. And this kind of minimum functionality should 
> be possible to be implemented in even the smallest 2,5G / 3G 
> cellular handsets. An example of dimensions for such a 
> handset could be 11 x 5 x 2 centimeters (1 inch = 2,54 
> centimeters). Could you compare such a terminal to a laptop 
> computer? Hardly.
> 
> Of course, then there are communicator / PDA type of devices 
> having bigger processor capacity and memory making it 
> possible to install more demanding applications in them, but 
> even those devices cannot (in my opinion) be directly 
> compared to laptops.
> 
> 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.
> 
> Cheers,
> 	 -Juha W.-
> 
> From: ext Tony Hain [mailto:[email-masked]]
> Sent: 04 March, 2002 21:04
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: Should connecting to the Internet be Optional? 
> 
> 
> Keith Moore wrote:
> > I think the cell phone requirements document would do well to break 
> > down the different cases:
> >
> > - cell phone with fixed functions vs.
> > - cell phone that can host applications
> >
> > - cell phone that is strictly an endpoint vs.
> > - cell phone that can provide net connectivity to other devices
> >
> > and examine requirements separately for each case.
> 
> I agree with one comment:
> > > The only way to prevent new applications
> > > from appearing on computing devices is to put the 
> executable code in 
> > > non-rewritable, non-replaceable, rom.
> > And require these devices to be tamper-proof ;-}.
> >
> > Feico.
> 
> Tony
> 
> Actually another thought; what is the difference between a 
> handset and a laptop that has an embedded 3G radio? Are they 
> both cellular hosts?
>

---

From: Phil Roberts <[email-masked]>
Date: Mon, 4 Mar 2002 15:43:31 -0500

> 
> If WLAN works differently from a cellular interface then it 
> needs separate consideration (maybe another draft). So this 
> draft wouldn't apply to interfaces for which cellular 
> requirements are not meaningful. But I'm not sure that 
> defining multiple technology hosts is the most urgent bit of 
> the work. I'd be mostly interested in seeing a document which 
> describes what needs to be implemented in the very short run 
> i.e. basic 3gpp v6 hosts. So it makes sense to me that the 
> document concentrate on these and then get updated later 
> if/when new requirements appear. 3gpp has an urgent need and 
> wants to deploy IPv6 so it's a good idea to provide guidance 
> to implementors through the cellular hosts draft.

Maybe we should call it the cellular interfaces draft????

> 
> Regarding Mobile IPv6, were you proposing that Mobile IP not 
> be considered in the cellular hosts document if we are only 
> describing requirements for basic cellular hosts and no 
> multiple-technology devices?

There are two issues - one is that it's not done, but hopefully soon,
and two that it implies multiple interfaces at this point because
at least in the 3gpp case it's not being considered for mobility
management within the cellular network.  But having the capability
there seems important and I would be hesitant to take it out.
It's probably wise to drop the references to HMIP and fast handover
as those are still some distance from standardization.

---

From: "Karim El-Malki (ERA)" <[email-masked]>
Date: Mon, 4 Mar 2002 21:43:42 +0100

> > The cellular host requirements draft is only aimed at minimum 
 > > cellular host functionality. So if a host has a DSL interface 
 > > this draft doesn't apply to it. I believe this is already an 
 > > assumption of the current draft. If instead you have multiple 
 > > wireless interfaces it would apply.
 > 
 > But if your multiple wireless interfaces include something like
 > WLAN it needs to be spelled out which of these recommendations
 > apply to which interfaces.  No?

If WLAN works differently from a cellular interface then it
needs separate consideration (maybe another draft). So this draft wouldn't
apply to interfaces for which cellular requirements are not meaningful.
But I'm not sure that defining multiple technology hosts is the most
urgent bit of the work. I'd be mostly interested in seeing a document
which describes what needs to be implemented in the very short run i.e.
basic 3gpp v6 hosts. So it makes sense to me that the document concentrate
on these and then get updated later if/when new requirements appear.
3gpp has an urgent need and wants to deploy IPv6 so it's a good idea
to provide guidance to implementors through the cellular hosts draft.

Regarding Mobile IPv6, were you proposing that Mobile IP not be considered
in the cellular hosts document if we are only describing requirements for
basic cellular hosts and no multiple-technology devices?

/Karim

---

From: [email-masked]
Date: Tue, 5 Mar 2002 09:18:22 +0200

Hi Tony,

> While we can't assume that everything is
> reasonable in the constrained environment, we also shouldn't 
> be throwing out capabilities that history has proven useful simply 
> because they are hard or cost a little more.

I think we'd appreciate more techincal comments on what you
thik we got wrong.  We've had the draft out for about 9 months,
and most of the feedback has been from folks who have been
considering how to optimize things.  I'm sure we may have
over-optimized, so specific recommendations on things
are appreciated.  Is it useful for us to also discuss
the applicability of some of these features (like when
& where to use them)?

> > => It doesn't. But this is a classical argument
> > which essentially says :'if you can't build it
> > now, wait for a few years and you'll fit everything
> > in'... well, as an engineer I don't have a major
> > problem with that, but if I was someone who's
> > trying to sell a wide range of products for
> > different market segments, and some of those
> > need to be limited in many ways to be sellable
> > at all, then I would have a problem with this
> > logic.
> 
> Product decisions beyond what is technically possible don't belong in
> calculator has more low-power CPU & memory than the SGI workstation I had 10 
> years ago, and it would fit in a package small enough for a 3G handset (and has a
> device design was done), so the fact that a product team doesn't want to 
> use those for a specific market is not a problem for the IETF.

Yeah, but my 4 year-old son's Mac (circa 1988) boots faster, doesn't
freeze and the software fits on a floppy - which is much more than I can
say about my laptop.  

Seriously, we are trying to consider IPv6 and ensure that it works, with a 
minimum amount of configuration, upgrading and a maximum of stability.
If you think that specific recommendations we have in our draft are
incorrect, please comment.

> While that is not a MUST NOT, it is a very strong instruction to avoid
> it. If it said something like 'A cellular host MAY choose NOT perform

That is a good point.

> If there is something specific that makes the statement true, it should
> be written here so people don't have to chase around to find it. The
> only thing that might make it true is that the router interface on the
> address, and will never use another format. This also presumes that the
> connected devices. If it does that then there is no guarantee 
> that some device on the allocated subnet will not collide.

OK, we'll check into adding text for this.

thanks,
John

---

From: [email-masked]
Date: Tue, 5 Mar 2002 09:25:32 +0200

Hi Tony,

> handset and a laptop that has an embedded 3G radio? Are they both cellular hosts?

Yes they are.  Our first attempt at the draft was very bias towards
devices that would have the v6 stack burned in, so modification was
near to impossible.  Additionally, 3GPP had some quirks in their
IPv6 usage, which would force implementations to do some different (non-standard)
thinks in order to work.  For the most part, those quirks have been
fixed.

So, we've tried more to discuss in what cases the requirements / functionalities
are needed.  For example, use of DAD on a cellular point-to-point link
may not be needed.

best regards,
John

---

From: [email-masked]
Date: Tue, 5 Mar 2002 09:33:40 +0200

Hi Phil,

> mentally thinking of PocketPC kinds of devices whenever I here

Could you re-read the intro to the draft and tell us what parts
are unclear - I'm probably a bit blind to the draft at the moment.

Anyhow, we specified the term 'minimum' to imply the base set
of features needed to ensure interoperability.  Anything
beyond that is seen as gravy.  Again, if some of our
recommendations are off-base, please let us  know.

thanks,
John

---

From: [email-masked]
Date: Tue, 5 Mar 2002 09:35:54 +0200

Hi Keith,

> > Anyway, we agree on the importance of the router case because
> > at least I personally believe the interesting stuff gets here when
> > we have Personal Area Networks and such.
> > 
> > Could do that in a separate document, though, seems there's
> > enough to discuss even if only hosts are mentioned ;-)
> 
> a separate document is fine w/me; 
> deferring work on such a document isn't.

Agreed. When this draft was first discussed (in London) there
was guestions about routing of packets, etc.  We tried to clarify that
in this draft, we are looking at host functionality.  

I do think that router / personal router issues need to be addressed.
I think that we would like to tackle the host issues first, but
router issues need to be discussed (preferably in a seperate doc).

thanks,
John

---

From: [email-masked]
Date: Tue, 5 Mar 2002 09:39:54 +0200

Hi Phil,

> apply to which interfaces.  No?

I think that we don't need to even divide things up amongst
wireless and non-wireless, as this might be an arbitrary 
division.  We do try to cover cellular links in this draft,
which have some special properties, and then discuss the
what requirements are for normal interfaces.  Most folks
view WLAN quite much like regular LAN links, so that we
did not think we need to be specific in that respect.

Anyhow, for all we know, some devices (which could even
be micro-devices) would have an ethernet port on them, 
in additional to a cellular radio.  

John

---

From: [email-masked]
Date: Tue, 5 Mar 2002 09:09:09 +0200

Hi Tony,

First off, in reply to your subject, I think that connecting to the Internet
is mandatory, or there would be no reason to be submitting this work to
the IETF.

> draft-ietf-ipv6-cellular-host-00.txt, which show it is clearly is not
> ready for last call. 

Its good to see technical discussion on the draft.  The authors really
do appreciate feedback on the draft, what is a good idea and what is not.

> While I am willing to believe that there  are valid
> reasons to make adjustments based on characteristics of the link, this
> document is fundamentally flawed because it is based around 
> the pretense that small footprint devices are somehow special. We MUST 
> NOT allow ourselves to modify well thought out architectural 
> fundamentals based on point-in-time engineering constraints that are dubious 
> at best. If a device wants to participate as an Internet node, there are basic
> requirements. Of course, participating in the Internet is optional, so
> if a device would prefer to avoid the requirements, it may choose to
> create its own universe.

The IETF is an (mostly) an engineering body and engineering is the science
of working with constraints.  I do think that discussion on what is appropriate
and what is not is a very good thing.  The IETF has chartered working
groups which do take considerations of devices, links, networks, so I don't
see what we have been suggesting is out of place.

> The argument that small devices have limited processors or memory
> overlooks the fact that the processor and memory of many hand-held
> devices today is significantly greater than the workstations that were
> available when IPv4 was defined. Interesting point; there was 
> no problem getting the stack and an array of applications to fit then. Another
> interesting point; there are frequently rumors that laptops 
> will include cellular interfaces, so where does the processing and memory 

In general, the authors approach has been to be conservative in what is sent
and generous in what is accepted.  Consider that many of the cellular hosts
will have limited configurability, limited upgradability, limited power
yet must be extremely robust - it isn't only about processing power or
memory limitations.

Additionally, most of the power savings on laptops & cell phones come
from the careful usage of resources, not due to increases in battery
technology - when considering signaling, I think it is a perfectly
acceptable consideration to see what is necessary to send and what is
not.  This is what we have been attempting to do in our draft.  

> On the subject of applications, the absolute BS about limiting the
> application set to avoid an IPsec requirement is something 
> that belongs in a product development discussion, NOT a standards 
> discussion. The one point that should be clear is that over time the number of 
> applications used via wireless (cellular or otherwise) will grow, and that we can't
> stack. To that point, we MUST reiterate that ***ALL IPv6 IMPLEMENTATIONS MUST
> INCLUDE SUPPORT FOR IPSEC***. If we relax that requirement, 
> applications will never be able to expect support, therefore will have to keep
> inventing their own mechanisms. The only way to prevent new 
> applications from appearing on computing devices is to put the executable code in

Tony, we are not looking at removing requirements for IPsec.  However, we
all know that IPsec is not a magic bullet, which will solve security
issues.  Again, we have been trying to deal as realistically as we
can with what security solutions fit into what scenarios.  In several
documents that I have been involved in, the IESG has commented on security
sections - stating that better thought needs to be given when
IPsec is used, dependancy in PKI, and what other methods are applicable.
This is the considerations which we have tried to bring up in the document.
If you feel that it is a MUST to implement IPsec on all devices that
use IPv6 & connect to the Internet, wouldn't it have been easier to say just that?

thanks,
John

---

From: [email-masked]
Date: Tue, 5 Mar 2002 11:15:29 +0200

Hi Phil,

> Maybe we should call it the cellular interfaces draft????

I think that would not be sufficient.  Currently, there is no
IPv6 hosts document.  If there were one, this discussion would
be shorter.  I would suggest that some sort of hosts document
is needed - it will be a big problem if many companies 
make devices with IPv6 that function poorly or badly.  I
would hope that our draft goes someway in ensuring some basic
compliance when companies start adding IPv6 to mobile phones.
This is a very real thing, most likely the IPv6 stack will
not be very upgradable / configurable.  

> as those are still some distance from standardization.

I feel that support for MIPv6 is important in the draft - at least
some discussion of it, where it might be applicable, etc. for
HMIP & FMIP, I'll leave it to the mobility experts to discuss it.

John

---

From: [email-masked]
Date: Tue, 5 Mar 2002 11:18:13 +0200

Hi Tony,

> The document is fundamentally flawed because it is focused on a target
> product, the micro-3G handset. If it gets rewritten to focus on unique
> exceptions for the cellular air-link that are strictly about 
> addressing the problems that arise from its characteristics, it MAY be 
> worthy of a WG last call.

As there are open issues with the document, I'm not worry about last call.
My intent is to get the requirements / features / functions correct.
I would hesitate to say the focus is on micro-3G handsets, but to get
a starting point for devices that are going to made, which work in 
constrained environments.  Hopefully some of my earier comments have
clarified things a bit.

John

---

From: Phil Roberts <[email-masked]>
Date: Tue, 5 Mar 2002 11:50:55 -0500

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Tuesday, March 05, 2002 4:15 AM
> To: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> IPv6 hosts document.  If there were one, this discussion 
> would be shorter.  I would suggest that some sort of hosts 
> document is needed - it will be a big problem if many companies 

I simply disagree with this.  On some devices this may be true,
but certainly not on all, and perhaps not even on the majority
of devices used for data operations.
  
> > and two that it implies multiple interfaces at this point 
> because at 
> > least in the 3gpp case it's not being considered for mobility 
> > there seems important and I would be hesitant to take it out. It's 
> > probably wise to drop the references to HMIP and fast handover as 
> > those are still some distance from standardization.
> 
> I feel that support for MIPv6 is important in the draft - at 
> least some discussion of it, where it might be applicable, 
> etc. for HMIP & FMIP, I'll leave it to the mobility experts 
> to discuss it.
> 
> John
>

---

From: Phil Roberts <[email-masked]>
Date: Tue, 5 Mar 2002 11:48:22 -0500

Sure.

"For the purposes of this document, a cellular host is considered to 
   be a terminal that uses an air interface to connect to a cellular 
   access network (i.e. GPRS, UMTS, CDMA2000) in order to provide IPv6 
   connectivity to an IP network."

As others have pointed out it's hard to be more ambiguous than this.
What is a terminal?

There is this in the abbreviations section:

"TE          Terminal Equipment. For example, a laptop attached 
               through a 3GPP handset."

And especially when you start talking about UMTS IMS capable devices,
one does not necessarily think of small, limited bandwidth, not updateable
with
new software, kinds of devices.

So the issue here is that it is anticipated there is about to be
an explosion of v6 capable cellular devices for 3gpp standardized
networks and that not providing guidance on host requirements may
make it difficult for such devices to interoperate?  A different
approach might be to write a v6 host requirements doc akin to 1122
and realize that device implementors may have to make intelligent
decisions about what not to include if it's not possible to include
everything specified in that.

Phil

> Sent: Tuesday, March 05, 2002 2:34 AM
> To: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Could you re-read the intro to the draft and tell us what 
> parts are unclear - I'm probably a bit blind to the draft at 
> the moment.
>

---

From: [email-masked]
Date: Tue, 5 Mar 2002 19:37:56 +0200

Hi Phil,

> "TE          Terminal Equipment. For example, a laptop attached 

TE is actually something quite different than terminal.  I think we should come up
with a different term than terminal in the document.

John

---

From: "Bound, Jim" <[email-masked]>
Date: Wed, 6 Mar 2002 12:25:01 -0500

I don't agree.  But I am thinking the authors bag the IETF and take this elsewhere unless we can agree on use vs compliant systems.

/jim

> ready for last call. While I am willing to believe that there 
> are valid
> the pretense
> that small footprint devices are somehow special. We MUST NOT allow
> ourselves to modify well thought out architectural 
> fundamentals based on
> point-in-time engineering constraints that are dubious at best. If a
> device wants to participate as an Internet node, there are basic
> no problem
> getting the stack and an array of applications to fit then. Another
> will include
> that belongs
> in a product development discussion, NOT a standards 
> discussion. The one
> point that should be clear is that over time the number of 
> applications
> used via wireless (cellular or otherwise) will grow, and that we can't
> stack. To
> that point, we MUST reiterate that ***ALL IPv6 IMPLEMENTATIONS MUST
> applications
> will never be able to expect support, therefore will have to keep
> applications
> from appearing on computing devices is to put the executable code in
> If a document on cellular requirements makes any sense, it has to be
> based on differences in fundamental characteristics of the 
> air link, not
> the device on either end. Avoiding DAD simply due to expense is not a
> valid justification, but if the loss characteristics of the 
> link make it
> more problematic than valuable, there may be an argument. Keep in mind
> applications where anonymity is most valuable (as one moves around and
> doesn't movement traced) are precluded. A non-zero probability of

---

From: "Bound, Jim" <[email-masked]>
Date: Wed, 6 Mar 2002 12:33:11 -0500

This doc should only be for 3G air interfaces and based on 3GGP rel 5
specifically.

It is not for WLAN or other air interfaces I know of being deployed
right here in the U.S. for IPv6.

/jim

> From: Phil Roberts [mailto:[email-masked]]
> Sent: Monday, March 04, 2002 3:18 PM
> To: 'Karim El-Malki (ERA)'; Phil Roberts; 'Tony Hain';
> [email-masked]
> > From: Karim El-Malki (ERA) [mailto:[email-masked]] 
> > Sent: Monday, March 04, 2002 3:14 PM
> > To: 'Phil Roberts'; 'Tony Hain'; [email-masked]
> >  > supported on the cellular interface rather than 
> > requirements  > for host?  Some substantial number of devices 
> > for which this  > is targeted will be dual network interface 
> > capable and for the  > other interface some of these 
> > optimizations don't make sense.  > 
> >  > device, which means the optimizations recommended on the 
> > cell  > facing interface in many cases SHOULDN'T be 
> > recommended on  > the other interfaces.
> >