No, I don't have a good example. But the error code is not reserved
specifically for this situation, so I wouldn't want to imply that it is.
Anyway, I'm OK with your text and also with the text that Paul proposed earlier.
Thanks,
Yaron
> -----Original Message-----
> From: Tero Kivinen [mailto:kivi...@iki.fi]
> Sent: Friday, December 11, 2009 15:45
> To: Yaron Sheffer
> Cc: Paul Hoffman; ipsec@ietf.org
> Subject: Re: [IPsec] #124: INTERNAL_ADDRESS_FAILURE error and how to
> continue.
>
> Yaron Sheffer writes:
> > I think Tero's text is somewhat speculative in assuming that this
> > error case only results from exhaustion of the address pool - I'm
> > sure there can be other reasons. Otherwise the text is OK.
>
> Can you give me example what other error causes can cause this error
> notification? Do you think they require any other type of handling
> than what is listed in my text?
>
> Anyway we can change the text to be following if that is better:
>
> If the initiator does not receive the IP address(es) required by its
> policy, it MAY keep the IKE SA up and retry the configuration
> payload (as separate INFORMATIONAL exchange) after suitable timeout,
> or it MAY also tear down the IKE SA (by sending DELETE payload
> inside separate INFORMATIONAL exchange) and retry IKE SA from the
> beginning after some longer timeout. The timeout should not be too
> short (especially if the IKE SA is started from the beginning), as
> these error situations are not fixed quickly, thus timeout should
> likely be several minutes. For example address shortage problem will
> only be fixed when more entries are returned to the address pool of
> the responder when other clients disconnect or when responder is
> reconfigured with larger address pool.
> --
> kivi...@iki.fi
>
> Scanned by Check Point Total Security Gateway.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
