RE: Clarification of potential NAT multiple client solutions

["William Dixon" <wdixon@windows.microsoft.com>]

Paul, are suggesting that new error codes for notifies and the notify
behavior be added to the nat-t spec as well ?  The authors had consensus
that we didn't want to do this.  There are a lot of reasons why a quick
mode might not be accepted irregardless of nat-t.  And since notifies
were optional anyway, we didn't see the need to add them to distinguish
between failures due to different implementation techniques.

-----Original Message-----
From: Paul Hoffman / VPNC [mailto:paul.hoffman@vpnc.org] 
Sent: Tuesday, July 30, 2002 8:42 AM
To: Brian Swander; ipsec@lists.tislabs.com
Subject: Re: Clarification of potential NAT multiple client solutions


Thank you for the quite useful list of alternatives. And thank you 
for listing the believed IPR issues for them. This makes things much 
clearer to implementers.

At 4:01 PM -0700 7/29/02, Brian Swander wrote:
>As this isn't a wire protocol matter, but a local implementation
>matter, specification of the mechanisms do not belong in the draft 
>itself.

Now that I have seen the list, I would disagree. That section of the 
current document feels like a bit of hand-waving, and having this 
list there (or at least in an appendix) would clear up some of that. 
This is particularly important because when a user cannot set up an 
SA, the UI will probably give some reasoning that will likely be 
different between different vendors because they chose different 
strategies. Having this material available to all implementers in the 
eventual standard would be valuable.

And, yes, you should keep in the IPR stuff, at least to mark the 
items for which IPR notices have been registered with the IETF. You 
don't have to say who or what, simply "An IPR notice for this options 
has been received by the IETF".

--Paul Hoffman, Director
--VPN Consortium