Re: Meeting straw poll

[Sheer El-Showk <sheer@saraf.com>]

> >                                                                 ... relies
> > on beep as the session layer makes it a poor candidate for me (I don't
> > think we can adopt a protcol that only supports beep).
>
> There is at least one technical comment in this - a single transport map.
> There may be a second one concerning the sessions mechanism, but I'd like
> to be sure before attempting to respond.
>

Well my point was more about using only one transport mechanism and
depending upon BEEP in particular as a session mechanism.  I'm not
strictly opposed to integrating another protocol to address part of the
needs of provreg (I think this is good reuse, so long as that protocol
doesn't come with a whole new suite of limitations), I'm just not sure I
like something as complex and untested as BEEP being integrated into a
protocol that's already supposed to be operational in high-volume
environments (and sadly enough we've missed that deadline already).


> >               ... the parrallel but only if they addressed sufficienty
> > different problem domains ...
>
> So, the transport mapping. One, several, or one per <what>?
>

Well, by problem domains I meant something a little more fundemental --
registrar-registry versus registry-registry (as you and Jordyn were
discussing).  As far as different transport mappings I see those as
different solutions addressing the same problem domain.  What I was saying
there is that I would like to see two different protocols only if their
usage was different enough that there would rarely be a question of
overlap or of using one protocol instead of the other.  I think we've done
too much in Epp to try and address the needs of everyone and I wouldn't
mind seeing it broken down into protocols which would rarely overlap in
the same operational environment (I think that a commercial gTLD registry is a
very different entity than a IP registry or even a ccTLD registry --
unfortunately we need to integrate accross a lot of these).

> Both multicast and unicast ... cast. Do they address sufficiently different
> problem domains? That just to get the juices flowing.
>
> The existence of a control and two or more (256 to be exhaustive) data
> channels per connection allows one tcp connection to connect two end
> points with two or more administrative roles, e.g., a single operator
> node offering access to two or more registries, and a single registrar
> node offering access to the same registries. Several gTLD operators now
> or may also be ccTLD operators, and presumably different polices apply
> to each registry, but no technical requirements necessitate protocol,
> transport, port, or even connection level isolation of one repository
> from another. The operations over these two channels are asychronous.
>
> The existence of a control and two or more (256 to be exhaustive) data
> "channels" per connection allows one tcp connection to connect two end
> points with two or more functional roles, e.g., an add and a delete op
> for distinct objects undertaken asychronously. An exhaustive example
> we see frequently is <check> for variation of name. One can run 255
> instances of <check> asychronously, as opposed to 255 instances sequentially.
>

I've looked over the BEEP rfc's and am pretty familiar with its virtues.
I think if BEEP were a more proven technology then I would be very happy
to see a protocol that maps naturally into it (though I still wouldn't
like tieing the protocol entirely to it).  I agree with you entirely that
it provides a lot of very nice functionality.  But even looking over the
BEEP Api's that are out there (and they are pretty limited -- only Java
and Phython that I found) and I would be loath to insist that any
operation registrar or registry needs to be able to implement or use such
a complex protocol.  Also, and I'm really not sure how XRP addresses this
(I havn't even checked), depending on such a "rich" protocol to handle
session management and authentication for you means that it is very
difficult to extract your base XRP protocol and implement it in a
different environment -- such as SMTP or even plain batch files.


> This note I hope motivates reading rfc3080 and rfc3081, and the draft
> available at http://nic-naa.net/draft-brunner-xrp-01.txt, at least the
> section on BEEP, or better still, the pending pre-ID version of the
> draft, draft-ietf-provreg-epp-beep-00.txt, which I'll get out in about
> a week. There are _lots_ of things a profiled, striped, set of paths that
> share end-points can do, that a single path can't, or can't do easily.
>

Right, but given that the protocol has to operate, under certain
conditions, in an environment with a single path, how are we supposed to
support this.

> I haven't addressed the aspect of authentication, another significant
> distinction.
>
> This gets us towards the <what> of the "one per <what>" view of transport
> maps, and your view was also expressed by Dave at the meeting. One view
> holds that connection == what, another view holds that asychronous !=
> synchronous, multiplex != uniplex, confidentiality + authentication !=
> confidentiality ... hence connection != what.
>

I'm really not sure I follow you here Eric, would you mind elucidating ...
what do you mean by one transport mapping per <what> where what ==
connection, or am I misunderstanding you?

> Personally I look forward to transport mappings for smtp (connectionless),
> http (1.0 c-less, 1.1 c-full, or cookie session provisioned), and for file
> system(s) (nfs/udp and afs/tcp).

Please tell me the NFS/AFS thing is a joke.  NFS has enough problems
working as a file sharing protocol without needing the extra burden of
authentication, confidentiality, and what not that we'de place on it ;->
Please let's not pull a "because we could" here.


Enjoy indian dining, wish I was there ...

Sheer