To:
<ietf-provreg@cafax.se>
From:
"Hollenbeck, Scott" <shollenbeck@verisign.com>
Date:
Wed, 17 Jul 2002 17:56:33 -0400
Sender:
owner-ietf-provreg@cafax.se
Subject:
Proposed Document Changes
While in Yokohama Ed, Jaap, Patrik, and I had a chance to talk through the questions and answers [1] that we need to resolve before Patrik would feel comfortable taking the provreg protocol documents to the IESG. Here's a summary of the changes that we think need to be made before the IESG will approve the documents: The core (epp-06) document: - All text describing "asynchronous" operation needs to be removed/reworded. Instead, text describing the protocol's operating mode as "client-initiated command, server response" needs to be reinforced. Without this change we'd need to define our own "congestion control/ack" service to handle the loss of instances that may be queued in the application queue-space (as when a server goes down). - Some ASCII art illustrating this operating mode should be added for clarity. - The description of the <status> command should be changed to describe the server's caching responsibilities. We agreed that the server should only be responsible for caching the identifier for the last command processed, thus if a response isn't received the client should send a <status> command before sending any subsequent commands. This should make <status> processing a lot easier for the server, and it's consistent with the protocol's command-response operating mode. It might also make sense to make the client transaction identifier mandatory instead of optional if the server doesn't have to cache identifiers for "a long time". - Fixing the authInfo data structure to make it extensible such that new authInfo mechanisms can be added in the future without having to change the core protocol document. The TCP transport (tcp-04) document: - Add some ASCII art describing the state machine for the protocol when carried over TCP. - Eliminate/reword all of the text describing "asynchronous" operation. Instead, it's OK to mention here that the client might be able to gain some performance efficiencies by pipelining commands, but that pipelining doesn't change the protocol's basic ping-pong operating mode. - Explicitly note that the length field in the header is in network byte order. I've also captured several editorial comments since we completed last call, and I'll get those in as well. If anyone has any issues or concerns with the above, speak up! -Scott- [1] http://www.cafax.se/ietf-provreg/maillist/2002-06/msg00015.html