To:
Sheer El-Showk <sheer@saraf.com>
cc:
Edward Lewis <lewis@tislabs.com>, ietf-provreg@cafax.se, jaap@sidn.nl, brunner@nic-naa.net
From:
Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net>
Date:
Fri, 10 Aug 2001 04:10:54 -0400
In-Reply-To:
Your message of "Thu, 09 Aug 2001 22:56:02 EDT." <Pine.LNX.4.33.0108092248570.11998-100000@laudanum.saraf.com>
Sender:
owner-ietf-provreg@cafax.se
Subject:
Re: Meeting straw poll
Sheer, > ... 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. > ... the parrallel but only if they addressed sufficienty > different problem domains ... So, the transport mapping. One, several, or one per <what>? 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. 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. 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. 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). Enjoy the weekend. Eric