Re: [btns] Minor connection-latch problem in AUTH48

[Nicolas Williams <Nicolas.Williams at sun.com>]

On Fri, Oct 16, 2009 at 02:13:13PM -0700, Laganier, Julien wrote:
> Nicolas Williams wrote
> > Perhaps the WG would say that we should REQUIRE that the key manager
> > initiate IKE/child SAs ahead of any triggering packet as a
> > simplification of the model (then we don't need a LARVAL state).  But I
> > could certainly see implementors not wanting to do that (for one it
> > makes the CREATE_CONNECTION_LATCH() call slow).
> 
> I think this is the external behavior that we want to capture. The
> specifics of how a given implementation achieves that need not to be
> specified in the RFC as long as the conceptual behavior is clear and
> guarantees interoperability.

Let me re-think the text.  Perhaps I'll simply add a note that an
implementor whose key manager does not immediately initiake IKE/child
SAs on CREATE_CONNECTION_LATCH() must have a larval state that we don't
describe.

Would that work?

> Both style of implementation would conform to that behavior, whether
> or not the triggering occurs directly as a result of latch creation,
> or indirectly via triggering by the first packet.

The external behavior will only show differences in timing.

> > An alternative would be to say "must" instead of "MUST" and then
> > explain that if the key manager does not initiate IKE/child SAs as part of the
> > CREATE_CONNECTION_LATCH() call, then it must have a LARVAL state that
> > we have not defined.
> 
> FWIW - from my perspective there's no difference between "must" and
> "MUST", RFC 2119 says about key word that "These words are often
> capitalized", but does not make it a must.

When those terms are used in capitals I think the intent is clear; when
they are not the intent may be clear from the fact that the same
document also uses those terms in capitalized form.

> > Indeed.  We don't absolutely need the LARVAL state.  Perhaps we should
> > describe it as an OPTIONAL state, since an implementation might not
> > have such a state at all.
> 
> I tend to think that we do not need the state at all. It is a valid
> implementation strategy, but it does not need to be captured in the
> standard since there are as-valid alternatives (e.g., Latch Manager
> triggers key Management directly)_

OK.  I'll propose new text later today.