Subject: Framing/Grouping Issues

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 05 Aug 2000 16:28:58 -0700

Roger, Ellen, and I discussed combining draft-ietf-ldup-framing-00.txt
and draft-zeilenga-ldap-grouping-00.txt into one specification.  The
former provides a framing mechanism (all operations between
the start and end belong to a frame) where the former offers a grouping
mechanism [all operations tagged with a "cookie" control belong to
a group].

We agreed that there were uses for both framing and grouping and we
agreed to create a combined I-D which supported both styles.  The style
would be prescribed by the OID associated with the frame/group type
(along with other semantics).  If you have concerns regarding this
"combined" or "dual" framing/grouping approach, please voice them
ASAP.

Also, we discussed the addition of "manage" frame/group operation
(no management semantics are defined).  We agreed to add this as
well.  If you have concerns regarding this addition, please voice
them ASAP.

	Kurt

---

From: "Albert Langer" <[email-masked]>
Date: Sun, 6 Aug 2000 14:30:18 +1000

[Kurt...]

[Albert]
Currently, the semantics of:
http://search.ietf.org/internet-drafts/draft-zeilenga-ldap-grouping-00.txt

are as follows:

***
5. Operational Semantics

  This section needs work.
***

When there is something in between the first and last line, (even though the
last line
is still there), please ask again.

This "first call" for a draft that hasn't been written is a bit like a final
call for a draft that has been deleted ;-)

The wonderful thing about ASN is that one can write out the syntax of a
protocol so
much more easily than with those horrible "packet formats" and ABNF specs.

The whole point of that is to avoid focus on relatively trivial syntax
issues and
get straight down to the actual protocol.

But one still needs some semantics before there actually is a protocol, so
that one can even begin to discuss it.

Semantics = meaning. The draft currently has no meaning, therefore the
question
has no meaning.

If for example, either a framing or a grouping or a combined
framing/grouping protocol was used to transmit "primitives" of an LADP
modify operation between replicas it could, just conceivably,
distract the attention of a WG from the fact that it has not defined a
protocol that preserves the operational semantics of the LDAP change
operation.

No matter how unlikely that may seem, I can think of an example, not a
million miles from here.

It could get even worse if somebody were to imagine that by specifying the
syntax for applying a set of operations to a set of entries, they have
either solved, or made any contribution towards solving, the problems of
actually applying that set of operations to that set of entries in a single
server system, let alone a multi-master system.

Ditto of course for the management of such a system.

I am concerned about standardised, combined meaninglessness ;-)

Yes, I do understand that a common syntax could be useful as a general
framework for many different types of grouping and framing, each with their
own specific semantics, and that the approach in this draft of simply adding
a cookie could well be common to all.

But I'd still like to see concrete example protocols before determining what
is common to them.

For example it may well be that protocols which require nested groupings
(5.1.5) have common requirements for the general framework to carry
additional information related to the restrictions on the types of groups
being nested and the sequence within which they are to be processed.

On the other hand, it may well be that simple framing, or even simple nested
framing, does not require a standard at all, since specifying it for any
protocol that needs it is just an ordinary use of the built in SEQUENCE and
SET facilities of ASN.

BTW Please take a close look at the (incomplete) protocol spec in MDCR. It
deals with treating a set of operations at different replicas applied to the
same entry as a single group with convergence to a common outcome. It turned
out to require carrying details of the tree structure of those operations in
the protocol. Just ensuring that they do reach a common outcome required two
separate sequence numbers, a version number and an originator identifier.

Once you consider that there may be more than one grouped operation
attempted (even at a single replica), against overlapping different sets of
entries, you are essentially dealing with "multi-DUA client operations" of
very similar complexity to "multi-master DSA replication" (for very similar
reasons - DUAs are independently and concurrently acting on the same data).

This is a HARD problem, even when not combining both aspects. That is why
neither transactions nor multi-master have been standardized up to now. It
doesn't get any simpler by defining a simple syntax.

It may become necessary for the protocol syntax to include for example
reference to a set of cookies of those other grouped operations that the DUA
is participating in or aware of, so that the server(s) can determine whether
any overlap is an actual conflict or a recursive nesting.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 11 Aug 2000 11:03:44 -0700

Albert,

I've provided draft-zeilenga-ldap-txn-00.txt which defines semantics
associated with a particular grouping type.  This draft, and the
grouping draft, are still a bit rough (in particular in regards
to error handling).  However, I hope this provides enough information
such that we might be able to reach consensus on the two questions
I previously noted in regards to the effort to combine the
grouping/framing syntactical sugar I-Ds into one I-D.

        Kurt

I wrote:
>We (the authors) agreed that there were uses for both framing and
>grouping and we agreed to create a combined I-D which supported
>both styles.  The style would be prescribed by the OID associated
>with the frame/group type (along with other semantics).  If you
>have concerns regarding this "combined" or "dual" framing/grouping
>approach, please voice them ASAP.
>