[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: LCUP Comment/Question
See response (JAM:) below.
John McMeeking
rvh@xxxxxxxxxxxxx
om (Richard V To: ietf-ldup@xxxxxxx
Huber) cc:
Sent by: Subject: LCUP Comment/Question
owner-ietf-ldup@m
ail.imc.org
07/01/2003 09:18
AM
> Two comments on the LCUP draft:
>
> [CANCEL] [text deleted]
>
> Should the Applicability section (Section 2) say something about the
> expected behavior of LCUP in a replicated environment? In particular,
> when an LCUP client disconnects and then reconnects, which case do we
> have:
>
> 1. LCUP is defined to work if it reconnects to ANY server holding a
> replica of the LCUP Context?
>
> 2. LCUP is defined to work only if it connects to the SAME replica
> that it was previously connected to?
>
> 3. this situation is undefined by LCUP and is determined by the
> implementation?
>
> 4. something else?
JAM: I think something like 3. It could work if the LCUP scheme supports
such a thing and all the servers involved support that schema. I hope that
some implementation will support this. But an implementation isn't /
shouldn't be required to support this. Maybe some words like:
Use of an LCUP cookie with multiple DSAs in a replicated environment is not
defined by LCUP. An implementation of LCUP may support continuation of a
LCUP session with another DSA holding a replica of the LCUP context. In
such cases, the implementation should document the LCUP Scheme used. In
the absence of knowledge about such support the client should not use a
LCUP cookie with any DSA other than the DSA which issued the original
cookie.
Or something that conveys the notion that it isn't defined by LCUP, but
isn't prohibited. And leave the door open for vendors (or later standards)
to address this. And the "document the scheme" part needn't involve
defining an OID and having the client request that format. I'd hope that
an implementation of LCUP in an replicated environment would support this
with its default LCUP scheme.
> Rick Huber