RE: Proposed requirements not met by current architecture and URP proposals - part 2 (end)

["Albert Langer" <Albert.Langer@xxxxxxxxxxxxxxxxxxxxx>]

[Albert]
>11) Design constraint on orderinig
>
>MM7.  Multi-master conflict resolution MUST NOT depend on
the in-order
>arrival of changes at a replica to assure eventual
convergence.
>
[...]

Concerning MM7, you seem to be suggesting that
it merely does not impose a requirement for strict
ordering on the design for multi-master. That could
be achieved by simply omitting it and perhaps
moving the explanation words elsewhere into a more
explicit statement within SM2 that it does not
apply to multi-master.

<rm2>Maybe it could be omitted, but SM2 is single master
and doesn't apply to multi master, and I (for one) would
rather say something then have a void on ordering.  The
dependence on ordering is very close to making a choice
between two general classes of implementation: state-based
versus change log and that's something that the WG will not
be successful mandating and has explicitly kept open in the
past.</rm2>

[...]

<rm2>I disagree.  If you go back through the archives, you
will see a lot of discussion of state-based versus change log
implementations.  Requirement MM7 says that either approach
may be used, because the state-based system may never be able
to send changes in the correct order.</rm2>

[Albert]
I noticed that when I went through the archives on first
joining the WG and have just taken another look. This
has heightened my concern that MM7 be removed or replaced with
something more neutral.

There are 3 plausible design choices that the *architecture*
can adopt for implementations conforming to multi-master standards.

a) Consumers MUST accept out of order changes from suppliers.

b) Suppliers MUST send changes in order to consumers.

c) Both of the above.

There are no other plausible options for interoperability such as
"leave it to the administrator" - that is merely a restatement
of c). Otherwise no interoperability is possible.

The current wording of MM7 clearly mandates option a) or c) and
prohibits adoption of the simpler option b) alone.

"MM7. Multi-master conflict resolution MUST NOT depend on the in-order
arrival of changes at a replica to assure eventual convergence."

That is consistent with the design choice made in the current
architecture draft and may well be the final outcome. But it is
clearly a design choice, not a requirement.

The reason for it you mention, "because the state-based system
may never be able to send changes in the correct order" could
well reflect a valid non-functional requirement such as:

"Design choices MUST reasonably balance the convenience of
implementation for state based and log based systems".

I'm not sure whether that should be described as a "resource
constraint", "architectural constraint", "policy constraint"
or what, but I'm not disputing it's a practical reality for the
WG.

Making that explicit would also cover your related remark:

"The dependence on ordering is very close to making a choice
between two general classes of implementation: state-based
versus change log and that's something that the WG will not
be successful mandating and has explicitly kept open in the
past."

But even without such an explicit additional requirement,
the arguments you mention could certainly be legitimately raised in
discussing the architecture and would undoubtedly prove
decisive if they stand up to scrutiny.

What I noticed when reading the discussions the first time,
and have confirmed again, is that these arguments *were* decisive,
but were *not* subjected to much scrutiny. Every other argument
pointed to a significantly more efficient and simpler design
with mandatory ordering. In particular MM7 essentially achieves
the exact opposite of G2 and MM1 by requiring a restart for any
interrupted replication session and also far more frequent
complete resynchronizations.

In my view it is quite clear that state based implementations
would not be inconvenienced *at all* by adopting option b).
All they need is a simple index in CSN order and they will
have to maintain that index anyway to support SM2 or an
equivalent design choice not expressed as a requirement.

The evidence for that is Active Directory, which is clearly
a state based implementation and does use option b) with
a simple index.

AD appears to be substantially more efficient than Novell's
implementation. Unfortunately Microsoft has not actively
participated in working out a design for interoperability.
So they have not challenged any of the bad design choices
in LDUP, although they certainly know better,
or at least hold an opposite opinion as to which design
choice is better than the choice which has prevailed in LDUP so
far on this issue, but have never argued for it.

[...]

<rm2>That may be true, but that should be determined by the
marketplace</rm2>

[...]

LDUP has no option but to make a choice between a), b)
and c). Even listing c) is stretching a point
simply because it is a logically possible choice.
Ultimately the real choice comes down to a) or b) and
adding administrator options to a protocol like this
conflicts with well known internet architectural
principles. But that of course is a design issue.

[...]

<rm2>Again, you are now into implementation and others
may not agree with you, so the requirements have to leave
other possibilities open</rm2>

Exactly my point. Anything I say about this is an
argument about design, not requirements. Please
try very hard to find a wording that enables
such discussion to be deferred until design
documents are being considered in the light
of requirements, rather than making it essential
to settle the issue during the next "final"
call on requirements by putting a design
choice in a requirements document.

[...]

>12) Design constraint on update tracking
>
>P2.  The supplier MUST track updates sent to the consumer
and not
>resend already acknowledged ones, even in the event of
recovery from a
>failed replica cycle.
>
>This is another unecessary design constraint. It is not
satisfied by
>URP and there does not appear to be anything unsound about
the URP approach
>of
>having the consumer track updates received rather than the
supplier
>tracking updates sent.

<rm>No, this breaks G3 and MM1 above</rm>

[Albert]
I think we might be at cross purposes.[...]

<rm2>[snip]...

I thought that there was mail already agreeing to change P2 to be
implementation neutral in response to other comments.

http://www.imc.org/ietf-ldup/mail-archive/msg00884.html
</rm2>

[Albert]
We were indeed at cross purposes. You appeared to be explicitly
arguing for the current text above. I am quite happy with
Steve's proposal (although simple deletion would be better):

***
1) The replication architecture SHOULD avoid sending to a consumer an
update that the consumer has already seen.

2) An update received by a consumer more than once MUST NOT produce a
different outcome than if the update were received exactly once.
***

The weakening to SHOULD in 1) does not authorize just deciding to send
duplicates anyway if a better approach is available, but permits
balancing the undesirability of that against other valid design
considerations that can be justified, rather than imposing the method
for meeting performance goals in the requirements document. Essentially
it leaves it up to the design to meet the other requirements while
demanding an explanation if the choices made result in any duplicates
at all. That seems unecessary to me, but it doesn't really matter.

The MUST NOT in 2) adds nothing but also does no harm.

Note that these two are consistent with a design change to eliminate
duplicates completely (which almost necessarily requires sending
in strict order), although not requiring such a change. But any such
design change *would* be prohibited by MM7.

>13) Transactional Consistency
>
>G2.  LDAP Replication SHOULD NOT preclude support for model 1
>(Transactional Consistency) in the future.
>
>P7.  The protocol SHOULD NOT preclude support of
Transactional
>Consistency (model 1).
>
>Model 1: Transactional Consistency -- Environments that
exhibit all
>four of the ACID properties (Atomicity, Concurrency,
Independence,
>Durability) [ACID].
>
<rm2>[snip...]

Well, I think that you may have some difficulty in convincing
the WG to drop model 1, but now I understand.  Also I point out
that Model 1 is not required, but that there was sufficient
consensus behind not closing the door on it permanently</rm2>

[...]

>14) Limited Effort Consistency
>
>G1.  LDAP Replication MUST support models 2 (Eventual
Consistency) and
>3 (Limited Effort Eventual Consistency) above.

[...]

<rm2>Ah, this is your opinion.  However, again I believe that I have
seen enough WG consensus to keep Model 3 on the books.  I think we
may have to agree to disagree here.

[snip]</rm2>

[Albert]
Agreeing to disagree is fine. Problem is that you are 
"agreeing to agree", which has no place in a standards
process. Unlike others that may be unnecessary, these
2 are simply meaningless.

I'm not going to be the one in difficulty
convincing anybody about anything. You're the bunny that
committed to:

<rm5>If URP goes to last call without (at least for me)
acceptible statements as to why it doesn't meet certain 
requirements, I'll try to be first in line saying "uh, I don't
see that you've met requirement <fill in blank> nor do I see
a statement as to why", that's all.</rm5>

http://www.imc.org/ietf-ldup/mail-archive/msg00838.html

So what answer is any author supposed to give as to *why* they
haven't made any attempt to not preclude support for model 1
and have provided no support for model 3?

There is nothing surprising about agreeable people agreeing
to agree and so reaching "consensus" not to drop something
without any intention of actually doing anything about it.
But that isn't part of producing a standards track protocol
for it.

If you are editor of a requirements document in a
standards process, it is your job to keep such "agreeableness"
out of it and make sure it consists only of operationally
meaningful requirements that can be applied to determine
whether or not those requirements have been satisfied.

I'm very impressed with the fact that you and Rick have
been able to turn a document that was largely meaningless
into one which *can* be used to ask such questions. I
wouldn't have thought it was possible, given the starting
point and environment. It's a shame to spoil that by undermining
the effect of those questions with 2 questions that are meaningless.

"Consensus" is no excuse. You are the guys that are supposed
to report back and point it out when a supposed consensus
does not actually mean anything. If you get instructed to
insert or remove something by a WG decision, after having
advised against it, that's a different matter. No such
instruction can be given to you as editors, without putting
it to the WG mailing list (not a meeting or a memo from John without
having actually *asked* the WG), and a public determination
reached by the co-chairs that a "rough consensus" does exist,
after giving you the opportunity to justify your recommendation
and others the opportunity to comment and record their views
on the specific issue that the WG is taking a decision about.

This mailing list is part of the public record of the
IETF standards making process. It is an engineering
process for producing actual internet protocols.
"Rough consensus" is the means by which
it takes decisions between mutually exclusive
alternatives, not a means for avoiding them, or for
recording Johns views on various subjects from day
to day, or rubber stamping the "room consensus" at
a meeting.

No such WG instruction has been given to you on this or
any other matter. The point is you haven't advised against
it so you are clearly identified as the authors of 2
"requirements" that you know, or ought to know,
are meaningless.

Having said that, I agree to disagree ;-)