To:
ietf-provreg@cafax.se
cc:
Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net>, Edward Lewis <lewis@tislabs.com>, jaap@sidn.nl, brunner@nic-naa.net
From:
Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net>
Date:
Sun, 12 Aug 2001 09:09:04 -0400
In-Reply-To:
Your message of "Fri, 10 Aug 2001 11:45:24 EDT." <Pine.LNX.4.33.0108100824530.18324-100000@laudanum.saraf.com>
Sender:
owner-ietf-provreg@cafax.se
Subject:
Re: Meeting straw poll
Sheer, Assume some transport-independent set of operations on some set of operands, e.g., draft-ietf-provreg-epp-04 et seq. The sense of the 3rd straw poll (the 1st being on draft-jseng-provreg-opp, the 2nd on the question of data collection remaining in the requirements), was on the adoption of: addition of a second transport mapping (first being tcp) addition of a push operator with appropriate operands addition of a second data abstraction mapping (first being flat) These consisting of a draft, a revision of an existing draft, and a draft, respectively, though currently packaged as a single draft called "XRP". For clarity, these are: draft-ietf-provreg-epp-beep-00.txt changes to draft-ietf-provreg-epp-04.txt draft-ietf-provreg-epp-containers-00.txt Co-chairs and contributors present at London please correct as necessary. > ... something as complex and untested as BEEP ... and later > ... loath to insist that any operation registrar or registry > needs to be able to implement or use such a complex protocol > ... and still later > ... how are we supposed to support this ... This doesn't appear to be a protocol specification concern, and rfc3080 is standards track. > ... by problem domains I meant something a little more fundemental -- > registrar-registry versus registry-registry Mechanisms for end-point initiation of instances of communication, e.g., "client" uni- vs "peer" bi-directional, are orthogonal to mechanisms for session management within an established instance of communication, e.g., rfc793 (none, see: segment, window, sequence numbers) vs rfc3080 (numerous), with mechanisms for end-point selection, e.g., registry, registrar, ICANN contract escrow agent, etc. From the context and your willingness for "Epp ... broken down into protocols wich would rarely overlap ... gTLD ... (RIR) ... ccTLD", I understand you to be interested in the business model, not the actual transport mapping, nor the EPP core. I hope this helps. It would help me if you could seperate specification issues from commercial operational issues. Eric