Subject: RE: [Mipshop] MIPSHOP discussion on new items and milestones

From: Narayanan Vidya-CVN065 <[email-masked]>
Date: Wed, 16 Mar 2005 12:58:46 -0600

The new charter looks reasonable to me. It seems appropriate to have the security for handovers within the scope of this WG. 

At the last IETF, I had mentioned at the Mobopts WG that we are currently working on a solution for AAA-based handover keys. Our goal is to have a v00 of the draft prior to the cutoff for the next IETF. We were originally going to target the Mobopts WG for this draft - but with the revised charter, it probably makes sense to send it to mipshop?

At Minneapolis, I had some discussion on the topic with Gerardo Giaretta, Julien Bournelle, Hannes Tschofenig and Christian Vogt on this topic. As soon as the draft is complete, I will post it to the group and start some discussions on the topic. In the meantime, if there are any particular issues or topics to consider within the scope of AAA-based handover key derivation, I'd like to hear about it. 

Thanks,
Vidya

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of gabriel montenegro
Sent: Wednesday, March 16, 2005 12:18 PM
To: [email-masked]
Subject: [Mipshop] MIPSHOP discussion on new items and milestones

Folks,

As you may be aware, the working group's current milestones are all done.

I spoke with Margaret Wasserman (taking over from Thomas Narten as our advising AD) during IETF week, about possible next steps for MIPSHOP.

It seems like there is sufficient interest and plenty of potential work items to keep the working group going. Possible items Margaret and I talked about include the following areas:

Further work on FMIPv6
----------------------

- work on MN-AR security. For example:

   - AAA-based keys for handovers - the need/desirability for such
	an item was brought out in Jari's presentation in MOBOPTS.
	even though this item does not yet exist in the form of
	an I-D, it seems we should not have major difficulties
	identifying interested parties to work on it.
	This item is limited in terms of the deployment scenarios
	it supports, but the carrier/service provider scenario it
	caters to seems important enough to warrant work on it.
	perhaps for PS?

   - derive key from SeND for fmip (Rajeev/Kempf draft)
	despite the IPR implications because of the use
	of CGA (from SeND), this could target PS

- work on FMIPv6 itself:

   - The above items will go a long way towards solving the security
	issues in FMIPv6. The current lack of such solutions is
	perhaps the major issue why FMIP is currently experimental
	and not PS. Given the above items, the WG could also take
	on the effort to revise the base FMIP to PS. This effort
	will clearly benefit from the fact that there are several
	implementations of FMIPv6 (including publicly available
	ones), so feedback from these effort will surely help in
	cleaning it up towards PS.

   - Apparently, the CDMA folks (in particular, those working
	on "1x-EV evolution" have some interest in using FMIPv6.
	Another potential WG item could be a document to describe
	how FMIPv6 would work over such a link. This document
	would be analogous to our current FMIPv6 over 802.11
	document, and would similarly target informational.

RR optimizations
----------------
I must confess to me these seem less coherent and ready as a group than the above group. E.g., it's not clear to me whether a standards-track document would end up mixing different proposals, and how.

- CGA type idea from OMIP
- CBA (credit-based) maybe no 'spot checks', just the basic stuff
	as is being applied to HIP, for example. this could complement
	other proposals like CGA or preconfigured MN-HA SA, for example.
- EBU - but have heard concern that this *increases* signaling cuz it adds
	messages, what we want is less (not more) signaling.

----

These are the two areas I see most probable for continued work. Nevertheless, there are other items people have mentioned. Feel free to propose additional items if you consider they are ready for standardization. This is diffucult to judge, but the following are things to keep in mind (of course, they are *not absolute
requirements*):

- are the proposals mature (e.g., plenty of discussion, several
	revisions taking into account WG feedback, published
	results, existing implementations, etc)
- is there interest in the proposals (e.g., are folks interested
	in deploying, perhaps because the proposal enables certain
	scenarios, is there interest from *more than one party*, etc)
- is IPR resolved (at least RAND as per IETF rules, hopefully
	royalty free of course)

Items not ready *now* may of course be ready later on. In the meantime, those items may continue being discussed in other working/research groups, as individual submissions, etc.

I have spoken with some of you about the above (thanks for the feedback). Even if you have privately expressed your opinions, please send your comments on the above items to the list. Besides expressions of support, negative opinions are equally important. I have purposely listed perhaps more items than we'll be able to take on, so we will probably have to cut the list a bit shorter. Hence, any comments to help in that respect are also very useful.

So please consider the rechartering discussion for MIPSHOP open (hopefully the directions mentioned above are close enough).

Comments?

-gabriel

_______________________________________________
Mipshop mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop

_______________________________________________
Mipshop mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop

---

From: "Soliman, Hesham" <[email-masked]>
Date: Wed, 16 Mar 2005 14:47:08 -0500

> Hello Hesham,
 > 
 > I don't see that this is urgent.  The two protocols
 > are largely independent, it seems to me.  There are
 > one or two things that could be done for improvements,
 > but they seem secondary to me.  

=> Ok, that's fine, we seem to have different priorities.
To me it's a primary goal.

   And, I would very much
 > hope that the integration effort would do nothing to
 > discourage running them independently -- at least in
 > the sense that FMIP does not start to depend on HMIP
 > or vice versa.  

=> Agreed. This is not my intention. My intention is to make
sure that a network operator _can_ deploy both simultaneously
if they want to. It's not a "must".

In particular, I don't think that
 > there should be any requirement for the anchor point
 > to "facilitate" handovers.

=> Well that's going a lot deeper than simply adding it
to the charter. Let's cross that bridge when we get to it.
But your statement is not that clear. The Anchor point is,
by definition, involved in IP handover, as much as an HA
is involved. Anyway, as I said, we can get to that in 
a requirements phase.

 > 
 > Is there a specific draft that you would recommend
 > for further details?

=> Nothing in the public domain. But some deployment experiences
are showing that the mix of anticipation and local mobility 
agents produce the best handover performance. This is not
a simulation.

Hesham

 > 
 > Regards,
 > Charlie P.
 > 
 > 
 > 
 > "Soliman, Hesham" wrote:
 > > 
 > >  > Comments?
 > > 
 > > => I think the items you listed all seem reasonable. Of 
 > course we need to discuss
 > > priorities. However, I would add the following item:
 > > 
 > > - Work on proposals for integrating FMIPv6 and HMIPv6. 
 > There are already
 > > drafts on this and previous discussions in MIP (before the 
 > split). I thnik
 > > the community will benefit from this, instead of providing 
 > two independent
 > > solutions that provide different optimisations but cannot 
 > coexist efficiently.
 > > I think this is more important than the RR optimisations items.
 > > 
 > > Hesham
 > > 
 > >  >
 > >  > -gabriel
 > >  >
 > > ===========================================================
 > > This email may contain confidential and privileged 
 > material for the sole use
 > >  of the intended recipient.  Any review or distribution by 
 > others is strictly
 > >  prohibited.  If you are not the intended recipient please 
 > contact the sender
 > >  and delete all copies.
 > > ===========================================================
 > >

---

From: Greg Daley <[email-masked]>
Date: Wed, 16 Mar 2005 21:27:14 +0000 (GMT)

Hi Christian, 

----- Original Message -----
[chop!]
> Still, one also needs to consider that separate EBU/EBA messages have
> advantages, too.  One such advantage is backward compatibility:  If 
> a CN does not understand an EBU message, and the EBU and CoTI messages
> are separate, the CN can just drop the EBU and respond to the CoTI.  
> Another advantage comes into play when combining EBU with direct 
> signaling [2].
>
> There was a discussion on this on the Mobopts mailing list shortly
> before IETF 62.

The direct signaling model can be left until later, but may benefit
from an extra CoTI.  Today this is a corner case though, and shouldn't
block EBU going forward (am a co-author on the mentioned draft).

I was also one of the people who siad that combining CoTI and EBU is
useful.

It doesn't need backward compatability since the method may be negotiated.

Gotta go, there's an aeroplane waiting.

Greg\\

---

From: "Mohamed Khalil" <[email-masked]>
Date: Wed, 16 Mar 2005 16:17:38 -0500

agree with Rajeev

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Rajeev Koodli
Sent: Wednesday, March 16, 2005 2:10 PM
To: Soliman, Hesham
Cc: gabriel montenegro; [email-masked]
Subject: Re: [Mipshop] MIPSHOP discussion on new items and milestones

Hi Hesham,

Soliman, Hesham wrote:

>- Work on proposals for integrating FMIPv6 and HMIPv6. There are 
>already drafts on this and previous discussions in MIP (before the 
>split). I thnik the community will benefit from this, instead of 
>providing two independent solutions that provide different 
>optimisations but cannot coexist efficiently. I think this is more 
>important than the RR optimisations items.
>
>  
>
I would keep the two designs separate so that they both can serve their
individual purposes. That would allow folks to deploy them in ways they see
fit.

-Rajeev

> > [email-masked] https://www1.ietf.org/mailman/listinfo/mipshop
> > 
>
>This email may contain confidential and privileged material for the 
>sole use  of the intended recipient.  Any review or distribution by 
>others is strictly  prohibited.  If you are not the intended recipient 
>please contact the sender  and delete all copies. 
>[email-masked] https://www1.ietf.org/mailman/listinfo/mipshop
>  
>

---

From: "Mohamed Khalil" <[email-masked]>
Date: Wed, 16 Mar 2005 14:52:44 -0500

Haseeb and my self are working in a draft related to this point.

Apparently, the CDMA folks (in particular, those working
>         document, and would similarly target informational.

Mohamed Khalil
Nortel Networks

---

From: "Soliman, Hesham" <[email-masked]>
Date: Wed, 16 Mar 2005 20:17:03 -0500

> >=> So how do you propose that they coexit? Does the MN send 
 > >two BUs every time it moves? If you don't see the need then
 > >  
 > >
 > That (two BUs) should work just fine, yes.

=> I don't think so. I can't see 2 BUs per handover being acceptable to
any network operator. I'd like to see if others agree/disagree with this. 
You didn't answer my question below: 

 > >I assume you still won't object if others in the WG work on this
 > >problem?

Hesham

 > >
 > >Hesham
 > >
 > > > 
 > > > -Rajeev
 > > > 
 > > > >Hesham
 > > > >
 > > > > > >=> People are already needing both though. It's up to 
 > > > us to decide
 > > > > > >whether we want to help or prevent people from using both 
 > > > > > efficiently.
 > > > > > >Why don't you want to make them coexist efficiently? Are you
 > > > > > >seeing a problem with this? I already mentioned that it 
 > > > would not
 > > > > > >stop each one from being used separately.
 > > > > > >
 > > > > > >  
 > > > > > >
 > > > > > Dependencies in design and deployment are not 
 > > > necessarily good for 
 > > > > > either protocol. Said another way,
 > > > > > we should specify protocols, let folks build systems. 
 > > > That allows 
 > > > > > differentiation for vendors, providers.
 > > > > > 
 > > > > > -Rajeev
 > > > > > 
 > > > > > >Hesham
 > > > > > >
 > > > > > >
 > > > > > > > 
 > > > > > > > -Rajeev
 > > > > > > > 
 > > > > > > > >Hesham
 > > > > > > > >
 > > > > > > > > > 
 > > > > > > > > > -gabriel
 > > > > > > > > > 
 > > > > > > > >This email may contain confidential and 
 > privileged material 
 > > > > > > > for the sole use
 > > > > > >This email may contain confidential and privileged material 
 > > > > > for the sole use
 > > > >This email may contain confidential and privileged material 
 > > > for the sole use
 > >This email may contain confidential and privileged material 
 > for the sole use

===========================================================
This email may contain confidential and privileged material for the sole use
 of the intended recipient.  Any review or distribution by others is strictly
 prohibited.  If you are not the intended recipient please contact the sender
 and delete all copies.
===========================================================

---

From: Narayanan Vidya-CVN065 <[email-masked]>
Date: Thu, 17 Mar 2005 12:33:23 -0600

James,
I agree with most of the points you mentioned below. In my mind, a protocol used to derive handover keys MUST NOT require any message exchanges between the MN and any AR at the time of handoff. All message exchanges must be completed and the handover key must be available prior to the MN handing off to another AR. That is why it seems like a mechanism like pre-authentication may in fact slow the handover sometimes. 

The AAA-based solution that we are developing has taken this as one of the requirements - that any message exchanges or key derivation must be completed prior to handoff. At the time of handoff, the key can be used to authenticate the FBU or the FNA, for instance, to the AR. 

Vidya

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of James Kempf
Sent: Thursday, March 17, 2005 12:25 PM
To: Gerardo Giaretta; Vijay Devarapalli; Jari Arkko
Cc: gabriel montenegro; [email-masked]
Subject: Re: [Mipshop] MIPSHOP discussion on new items and milestones

Gerardo and Vijay,

I agree with Jari that really nothing is needed other than as described in handover key draft. But, of course, I'm a co-author on the draft, so you'd expect I'd say that. :-)

That said, I'm willing to take a look at an AAA key mechanism. However, before MOBOPTS refers a solution to MIPSHOP, I'd like to be sure that the solution has a compelling handover optimization mechanism. This issue is actually currently being discussed in 802.11r, and I believe PANA in IETF. The proposed solutions I've seen so far involve either having the MN set up state with multiple network entities (ARs for this case) using preauthentication which requires managing that state  or involve round trips back to the AAA-H during the handover window which can make handover slow.

The advantage of the handover key technique is that it involves one round trip to the current AR outside the handover window. In addition, the only state involved is on the current AR or perhaps the previous AR, until the MN completes handover and gets a new key on the new AR, making managing the key much easier. The disadvantage is that address provisioning on the MN is constrained to use SEND CGAs.

            jak

----- Original Message ----- 
From: "Gerardo Giaretta" <[email-masked]>
To: "Vijay Devarapalli" <[email-masked]>; "Jari Arkko" <[email-masked]>
Cc: "gabriel montenegro" <[email-masked]>; <[email-masked]>
Sent: Thursday, March 17, 2005 9:59 AM
Subject: RE: [Mipshop] MIPSHOP discussion on new items and milestones

Hi Vijay and Jari,

>
> hi Jari,
>
> Jari Arkko wrote:
>
> > - MN-AR security is a significant issue in current specifications, 
> > and as such addressing it would be really useful. But I wonder about 
> > the need to have two different solutions in this space. Seems like 
> > James' draft would technically work in all scenarios. What he said 
> > about the IPR sounded positive too (but I am not a lawyer nor have I 
> > looked at the relevant patents).
>
> in some networks, where there is access network authentication using 
> AAA access, it might make sense to setup keys for securing FBU along 
> with access authentication. so, I think we should take a look at this 
> solution too.
>

I agree with Vijay. I think that in networks where a AAA infrastructure is deployed it could be reasonable to exploit this infrastructure and the network access authentication to bootstrap other security associations (a sort of SSO approach for network services). This has been considered for MIP6 bootstrapping, but it could be considered for FMIPv6 and HMIPv6 as well.

--Gerardo

> Vijay

Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A.

====================================================================
CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to [email-masked]. Thank you ====================================================================

---

From: "Soliman, Hesham" <[email-masked]>
Date: Thu, 17 Mar 2005 13:35:45 -0500

> I am not sure if this is true. I think we need to support 
 > AAA-based key derivation mainly because not everyone has 
 > deployed a PKI, while AAA infrastructure has been widely 
 > deployed. 3gpp2 relies a lot on AAA and so, there seems to 
 > be enough demand for a AAA-based solution. 

=> I don't think Jari was talking about PKI. Idon't mean to speak
for him but there are other options like CGAs that don't require
any PKI. 

Hesham

 > 
 > More than any technical advantages of a AAA-based approach, 
 > it seems to me that the main advantage is in leveraging 
 > existing infrastructure. 
 > 
 > Vidya
 > 
 > From: [email-masked] 
 > [mailto:[email-masked]] On Behalf Of Jari Arkko
 > Sent: Thursday, March 17, 2005 12:18 PM
 > To: Vijay Devarapalli
 > Vijay Devarapalli wrote:
 > >>- MN-AR security is a significant issue in current 
 > specifications, and 
 > >>as such addressing it would be really useful. But I wonder 
 > about the 
 > >>need to have two different solutions in this space. Seems 
 > like James' 
 > >>draft would technically work in all scenarios. What he 
 > said about the 
 > >>IPR sounded positive too (but I am not a lawyer nor have I 
 > looked at 
 > >>the relevant patents).
 > >>    
 > >>
 > >
 > Maybe. But only if the other solution has a drawback
 > that the AAA based solution could fix, such as better 
 > efficiency, higher security, or ability of service providers 
 > to get additional money. Is there such an advantage? (If the 
 > solutions are similar from the user's point of view, I don't 
 > think we need several solutions.)
 > 
 > --Jari
 > 
 >

---

From: Narayanan Vidya-CVN065 <[email-masked]>
Date: Thu, 17 Mar 2005 16:48:41 -0600

My understanding of James' draft was that it required router certs - but, it has been a while since I looked at it. So, I could be wrong. 

About v4/v6, I fully agree with you. Regardless of what the I-D might have applicability to (v6 only or v4 and v6), we need to consider both v4 and v6 for deployments. I would like a solution to be applicable to both v4 and v6 ideally. 

Vidya

-----Original Message-----
From: Jari Arkko [mailto:[email-masked]] 
Sent: Thursday, March 17, 2005 3:21 PM
To: Narayanan Vidya-CVN065
Cc: [email-masked]
Subject: Re: [Mipshop] MIPSHOP discussion on new items and milestones

Narayanan Vidya-CVN065 wrote:

>I suppose one could say, as James said, that router certificate 
>provisioning can be viewed as not requiring a full PKI.
>  
>
Yes. I'm not sure if his handover key draft requires router certs, when I looked at it again a couple of hours ago it didn't appear to do so. But maybe it needs to, I don't know. In any case deployment of server-side certs has proven to be relatively easy in many environments and 
applications,
e.g., web. I've had TLS server side root certs and path validation in my cellphones for the last 3-4 years, for instance. This is quite different from deploying client side certs. In fact, I don't know of any client side cert deployment that would be of the magnitude that is required for service providers. Private organizations yes, but millions of customers no...

>On another note, I can see the AAA-based solution being applicable to 
>v4 fast handoffs as well, in addition to v6. The CGA-based approach is only applicable to v6. Probably not a critical point though.
>  
>
Not sure if its a critical thing for MIPSHOP. But I personally believe 
dealing
with both v4 and v6 is important in almost any type of new Internet 
technologIy.

--Jari

>From: Jari Arkko [mailto:[email-masked]]
>Sent: Thursday, March 17, 2005 12:50 PM
>To: Narayanan Vidya-CVN065
>Cc: [email-masked]
>Narayanan Vidya-CVN065 wrote:
>
>  
>
>>Jari,
>>I am not sure if this is true. I think we need to support AAA-based 
>>key
>>derivation mainly because not everyone has deployed a PKI, while AAA infrastructure has been widely deployed. 3gpp2 relies a lot on AAA and so, there seems to be enough demand for a AAA-based solution.
>>
>>More than any technical advantages of a AAA-based approach, it seems 
>>to
>>me that the main advantage is in leveraging existing infrastructure.
>> 
>>
>>    
>>
>I agree with your arguments against PKI-based solutions. But where did 
>PKI come from? I don't see a proposal on the table that is based on 
>PKI. James' draft is not based on PKI. In fact, its based on completely 
>zero-config security so it could run on any network, if I have 
>understood correctly.
>
>Note that I'm not trying to argue in favor of James' solution. I'm just 
>reacting to the notion that we need multiple handover key solutions. Of 
>course, we could have a situation where they have very different 
>characteristics that lead to a requirement that we need to do both 
>(e.g. AAA is very fast and James' draft is zero-config). Or that they 
>are complementary in the same manner as home test and care-of test 
>optimizations are in RR. But so far I have not seen anything that tells 
>me this would be the case.
>
>Lets document the different user impacts that demand two mechanisms, if 
>there are any in this case. Otherwise lets just do one scheme, either 
>AAA or James' thing.
>
>--Jari
>
>  
>

---

From: [email-masked]
Date: Fri, 18 Mar 2005 15:59:56 -0600

Hi Jari,

>So are you saying that in your opinion there is no need for immediate
>RO enhancement and that's the reason why general purpose mechanisms
>are not needed at this point in time? I can understand this argument,
>even if I don't necessarily agree. But I have harder time understanding
>how we simultaneously need to progress precfgkbm and cn-ipsec
>if, as you say, there is no need and, in addition, the solutions have a
>limited applicability.
>
>Note that I'm not proposing that the one or two new methods be made
>mandatory, or be forced upon anyone. But in order to put this in our
>products we need to be nice and allocate suitable option numbers.
>All I'm asking is a level playing field, the same chance
>that other schemes of similar maturity and history (precfg~cga~
>ipsec) have been given.

The Precfgkbm and cn-ipsec IDs are pretty simple and
straightforward. Precfgkbm ID is essentially a couple of paragraphs
(there is probably more text in the boilerplates :)) and the cn-ipsec
ID is a couple of pages as compared to the CGA ID. Of course dont
interpret ID length as the criteria being used in determining what
gets standardized :) 
But my point is that these IDs are well understood by the community
and hence are being standardized at this time. I do agree with you
that none of these schemes will be mandated for MIP6. 
The CGA based proposal however has not had as much discussion. My
suggestion is that it would make sense to have some discussion on this
proposal before taking it up in the MIP6 WG. Of course you could
possibly drive a discussion and some reviews of the CGA ID on the MIP6
list and based on the outcome of that we could progress it here as
well. My suggestion was simply that it may be more productive or maybe
faster to get MOBOPTS to do this analysis. The playing field for all
RO schemes (which are non-mandatory) is the same. 
So the ball is in your court in terms of deciding how to proceed. If
you think that the MIP6 WG should take this work up in parallel with
precfgkbm and cn-ipsec IDs, then it would be best to get some
discussions started on the ML and following that we can do a consensus
call before making it a WG document. 

>--Jari

-Basavaraj

---

From: "Soliman, Hesham" <[email-masked]>
Date: Wed, 23 Mar 2005 14:26:05 -0500

> This may not be everybody's favorite list, but hopefully it 
 > works reasonably well
 > (or at least *maximizes the distribution of unhappiness*, as 
 > Brian put it at the plenary).

=> I like that quote :) It's good enough for me.

Thanks,
Hesham

 > 
 > comments? close enough, way off?
 > 
 > -gabriel
 > 
 > 
 > 
 > 
 > 	
 >

---

From: "Soliman, Hesham" <[email-masked]>
Date: Wed, 23 Mar 2005 18:36:14 -0500

Gab, 

I guess you're considering these comments for the charter
so I feel obliged to correct a comment below from James:

 > 2)  Of the security alternatives mentioned in the discussion 
 > for HMIP,
 > aggregate security is unacceptable because it does not 
 > provide the access
 > network with protection against a mobile node that obtains 
 > the certificate
 > of a roaming partner and presents itself as a client of  the 
 > roaming partner
 > when it is not. 

=> This is _only_ possible if:
- Someone forged a certificate (we can clearly ignore this)
- Someone stopped being a customer of such operator

In the latter case stopping being a customer would remove
all the credentials associated with the operator. The certificate
is one of those. Today this is simply done by disabling the SIM
card (in networks that use them). 

Hesham

---

From: [email-masked]
Date: Thu, 24 Mar 2005 16:54:51 -0600

> 
> > I believe 3GPP2 has stated that they are happy with RR
> > as stands, so I see no tearing hurry to standardize alternatives at
> this
> > time.
> 
> Could this be because they are not using it? :-)

Well... Route optimization is always optional for an MN.
Unless the PP2 specification (835-D) explicitly says that RR based 
RO is forbidden, I would say that it is a part of the PP2 standards
and to be seen if it is used when deployed.

> Alper
-Raj

---

From: Greg Daley <[email-masked]>
Date: Fri, 01 Apr 2005 00:32:49 +1000

Hi Jari, 

----- Original Message -----
From: Jari Arkko <[email-masked]>
Date: Thursday, March 31, 2005 5:58 pm
Subject: Re: [Mipshop] MIPSHOP discussion on new items and milestones
[Content Chopped]
> Let me rephrase the arguments slightly differently. I apologize
> the use of sarcasm to highlight a point, but I want to get to the
> bottom of this issue. Any resemblance to actual arguments
> made on the list is purely coincidental ;-)

It's now past midnight here, so sarcasm is perfectly acceptable.

At least for today.

Greg