Re: Message Pushing and TCP Transport

[Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net>]

Dan, Peter, and Chris,

If your issue is process, then please direct your remarks to the Chairs, and
to the process issue. Your claim must of necessity be that at some point the
chairs did find that "rough consensus" existed for poll-only state management.

This is distinct from finding that consensus existed to adopt a particular
document or set of documents, and to exercise change management over them,
unless you also claim that the documents were in final form last week.

Personally I concurred in adopting Scott's initial draft, I just don't think
they are in final form, yet.

Please let me know when and how that is reflected in the record of the WG, as
I've advocated against over-specification since the kick-off in San Diego, and
what you propose is unnecessary overspecification of the event model.

I don't mind being on the "loosing end" of whatever happens, we just pick up
our EPP extension drafts (in the I-D Administrator's queue this week) and put
them back into XRP-is-a-compeating-protocol format, and take our chances with
the process. May the better draft(s) win.

If your issue is something other than process, then I'm happy to respond to
any and all technical issues.

I do share your "show me" skepticism about feature-creep, and those who are
currently RRP celebrants would reasonably view any deviation from the core of
that protocol as "feature creep". But lets work through the details before
reaching conclusions.

The following four use cases involve a change of state at the registry:

	o object transfer
	o planned (and unplanned) maintenance
	o billing events
	o watch services (whatever thay may be, some random event model)

We have discussed transfer, in all four of our face-to-face meetings (-51,
-50, the pre-50 interim, and the -49 BoF), and on this list, and a list [1]
each of you (Dan, Peter and Chris) are aware of.

Fundamentally there are three parties, the winning and loosing registrars
and the registry. The winning registrar initiates the transfer. The problem
to be solved is how the change of state in the registry is communicated to
the loosing registrar. Numerous mechanisms exist. Fundamentally all the "poll"
mechanisms require some temporal guarantee that the transfer will not take
place until a poll-timer has expired. This requirement is absent where state
change notification may be initiated by the holder of the changed state. 

One common implementation mechanism is a hold-down timer, the other is a
listen process. Both are the subject of first-year programming curricula at
technical colleges. Neither are particularly complicated.

When we look to "advantage" of one mechanism over the other, we need to look
beyond the single-instance transaction. Scott clearly anticipated this in
draft-ietf-provreg-epp-04.txt, 2.9.2.3 EPP <poll> Command.

If we [servers] (para 2)
	operators SHOULD consider time-sensitivity and resource management
	factors when selecting a delivery method for service information
	because some message types MAY be reasonably delivered using non-
	protocol methods that require fewer server resources.

and if we [servers] (para 3)

	"MAY implement other mechanisms to dequeue and deliver messages
	if queue maintenance needs exceed resource consumption limits.

then push is at least as good a mechanism as going out-of-band, or dropping
the transactions on the floor. Personally I consider either of the latter
non-solutions, or errata to an incomplete protocol specification.

Design and implementation of a per-registry out-of-band notification handler,
or a per-registry silently discarded transaction discovery rule, appear to be
interesting technical challenges.

Broadly, we're looking at the scaling properties of the protcol, as the
volume of transaction increases, and as the volume of transaction participants
increases, and not the single-transaction instance.

The planned (and unplanned) maintenance events don't have a state change
initiator corresponding to a "winning registrar", and the "watch service"
from our (specification) perspective is a random interrupt generator. Both
affect one or more registrars per event.

The billing events may be predictable from the concerned registrar, thus
amenable to registrar-initiated discovery via poll, but there is no real
guarantee that a registrar's finances are well-known, even to the registrar.
Quite a few complicated business rules concerning reserves, margins, and time
are known to exist.

How do you propose to solve these?

If its technical, to me. If its process, to the chairs, and _not_ to me.

Eric

[1] defunct since 1 May.