RE: Issue 83 will be withdrawn

["William Dixon" <ietf-wd@v6security.com>]

Thank Ted & Steve for the explanations. I apologize for the delay.
Unfortunately, I'm not in a position to argue why this is a good thing, not
just a troubleshooting aid. I agree that for dedicated purpose IPsec
implementations this ICMP is not required - but then neither perhaps is
interoperability...

I'll note that host OS IPsec implementations (or some combination of code
within the stack) already have to process the ICMP Dest Unreachable for TCP
PMTU. It may not actually be "the IPsec driver or component" exactly that
does the processing. The discussion here sounds like you are not considering
all aspects of the host OS TCP/IP stack functionality involved in enabling
IPsec.

I'm very concerned that host OS implementers are not speaking up on issues,
given that they can fully change any part of the stack they want to when
they integrate IPsec functionality into the release, and they may be faced
with greater needs for interoperability.

Since I've been the only one recently interested, drop away...

> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com 
> [mailto:owner-ipsec@lists.tislabs.com] On Behalf Of Theodore Ts'o
> Sent: Tuesday, April 06, 2004 3:11 PM
> To: William Dixon
> Cc: 'Stephen Kent'; ipsec@lists.tislabs.com
> Subject: Re: Issue 83 will be withdrawn
> 
> William,
> 
> The discussion (what little there was of it) basically 
> revolved around doing the following:
> 
> 	* Making generation of the ICMP messages a "MUST"
> 	* Making generation of the ICMP messages a "SHOULD"
> 	* Making generation of the ICMP messages a "MAY"
> 	* Not talking ICMP messages at all (which is what we 
> did in IKEv1)
> 
> The concern with "MUST" was that this would be problematic 
> for high-speed IPSEC devices.
> 
> The concern with "SHOULD" was that from the point of RFP's, 
> SHOULD often turn into "MUST"'s, and this would be painful 
> for some vendor.
> 
> The argument against "MAY" was that given that the ICMP codes 
> were already defined, there was no value in reprinting them here.
> 
> When this issue was raised, there was relatively little 
> discussion, which is why we settled on simply dropping issue 
> #83.  So I wouldn't necessarily characterize this as a 
> consensus decision, as much as a decision based on Apathy.... 
> 
> Does this satisfy your concerns, or would you like make an 
> argument for one of the other above options?
> 
> 						- Ted
> 
>