Re: Pushing vs. Pulling

[Eric Brunner <brunner@nic-naa.net>]

> Speaking as the WG chairs, we'd like to make a few comments about the
> push-pull debate.

Thanks Ed, Jaap, this is good chairing.

> There is a consensus in the group that the group wants one protocol.  We
> take this to mean that a registrar doing business with two different
> registries wants to use just one set of software.  Please allow me to delve
> into a somewhat arbitrarily concrete example.  Let's say I want to register
> names in .com and .biz.  Would I expect to be running a (software) client
> from each, or should one client be sufficient.  As it seems the group's
> desire, it would seem to me to have just one client.  (Our question: is
> this a good assumption?)

Sigh. This is only one area where lines blur. Taking off a hat I've worn to
the point of acute discomfort, I write today as an individual participant.

There exist two, possibly more, distinct implementations of a "client". This
would be "good" in the usual IETF sense (of advance to DS iff 2 independent
implementations exist), but there are complications. One implements an IDL
initially published in April, and subsequently revised, that approximates
the current drafts. One implements an approximation of the current drafts,
without the benefit (or detriment) of an IDL. Both exist in win32 and *ix
forms, and both expose JAVA and C/C++ APIs. Both (last I checked) attempt
to impose additional constraints (cruft for trademark in the IDLized one,
and cruft for listening in the other).

I'll let the registrars, NSI, Register, Bulk, Tucows, MIT, etc., offer the
definitive answer on whether they will use "one client" (Tucows') when .biz
goes live, and also whether they will use the "same" client, or will or have
already written a client.

The desire to have "just one client" is defensible if we are concerned with
those of who don't intend, unlike some of the above, to implement a second
(in a series of "seconds") client. If we are concerned with those who were
going to roll their own anyway, then we are over-specifying, probably with
the effect of selecting business models, e.g., registrar product definition
vs registry product definition. That's how I read the subtext.

> Now, the chairs realize that this is the IETF and organizations don't count
> for much, and that we are to be looking beyond the registration of domain
> names.  But we want to determine if there should be a latent assumption of
> any client software should speak full EPP (or whatever) in order to speak
> with all registries.

Should the (hypothetical) universal client be capable of provisioning
registry-specific stuff, e.g., trademark for .info, and doing so via
registry-specific mechanisms, e.g., pushed trademark "watch" notices for
.biz, and that over specific registry-profiled AAA and transport mandates,
e.g., enSASLed BEEP for .biz?

I haven't even touched the sTLDs, that may have an additional sponsor cookie
to push through the registrars to the registry, or the ccTLDs, let alone the
RIRs, which may most resemble the model of pre-ICANN memory in com/net/org.

I don't see a rational way around more than one manifestation of a client,
even if the client is feature-fat, and the "just one" position reduced to
"sorta just one, but not really".

> The chairs don't want to make a technical decision on behalf of the group.
> (Not that we feel we are being compelled to do so at this time.)  It seems
> that there is no clear winner amongst "pull" and "push" technically -
> although some folks have strong opinions.  (No clear winner = no clear
> consensus.)  But to state the WG problem - the group needs to decide and to
> do so in a timely manner.

I agree, and the limits of the pseudo-debate have prevented us from attempting
to be rational about existing scaling problems. .com is throttling registrars,
and somewhere in that truth there is one or more instances of what we call in
the transport area "unfair aggressive", usually in the context of some hack
on tcp. A similar system known to .biz has its share of thrash. Adding state
push may not be a cure so much as a concealment of existing latent design
deficiencies.

> It is clear that there are strong preferences for one or the other,
> understandably so.  But, to the strong proponents of one or the other,
> let's move away from trying to prove "'my' way is right" to some try to
> find middle ground.  (Perhaps this can't be done, but let's give it a go.)

I'm aesthetically attached to event model symmetry, hence to push. Then again,
I'm aesthetically attached to an operating system.

> BTW, the Push-Pull straw poll did have one benefit.  Scott suggested that
> polling is a MUST, pushing a MAY.  Perhaps this is the middle ground to
> build upon.  (Comments on this, please.)

We could poll registrars just as easily as we poll registries, and registrars
could optionally push (urgent or meta-transactional) events just as easily as
registries do. There is nothing holy about which calls listen.2, and which
calls connect.2

The problem arises if one is optional. We now have to dig ourselves out of
a modest hole. What is the specific behavior whan a client fails (or just
fails to listen.2)? How can we avoid being normative and "in-band" where the
current text (epp-04 2.9.2.3, para 3) allows "other mechanisms"?

MUST NOT is way clearer, easier to specify, though not what I suggest.

> Other than that, there is nothing significant in the poll results (some
> wanted one, some wanted the other).

As has been pointed out, the simplest to implement form of <push> in a <poll>
dominated model requires a distinct session. The attraction of <push> may be
dependent upon the second connection, suggested by Scott earlier, or some
other means, such as a multiplexing session layer on a single connection, my
shorthand for BEEP.

Eric
(again, writing as an individual contributor)