Subject: Proposed Document Changes

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 17 Jul 2002 17:56:33 -0400

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

---

From: "Liu, Hong" <[email-masked]>
Date: Tue, 23 Jul 2002 23:40:52 -0400

Scott,

I assume you resend this to see if there are more comments. I don't mean to
beat up the dead horse, but I would like you to clarify the two paragraphs
quoted below.

The first quoted paragraph, could you explain a bit why "congestion
control/ack" need to be defined if the proposed change is not made? Do you
mean application level framing for flow control (windowing mechanism)? I
just want to understand it.

The second quoted paragraph, could you clarify:
(1) What is the last command processed? Is it the last command per registrar
(client) or the last command per session of the client? I assume that a
client is allowed to established multiple sessions with the server.
(2) Why is <status> command ever needed if its use is so restricted? The
client can simply resend the command if it does not hear from the server
after a timeout. EPP ensures idempotency for each command, so there is no
harm to resend it.

Thanks in advance!

--Hong

-----Original Message-----
From: Hollenbeck, Scott [mailto:[email-masked]]
Sent: Wednesday, July 17, 2002 5:57 PM
To: [email-masked]
Subject: Proposed Document Changes

[snip...]

[snip...]

[snip...]

-Scott-

[1]

---

From: "Gould, James" <[email-masked]>
Date: Wed, 24 Jul 2002 09:43:06 -0400

Scott,

I really don't see the value in the <status> command.  In its proposed form,
it doesn't provide any value to the client, since the client will most
likely have a pool of sessions and finding the status of the last command
processed on any one of the sessions doesn't provide any valuable
information.  There is even more of an issue of supporting the <status>
command for non-transform commands, where determining if a <check> was
successfully processed is pointless and represents huge overhead for the
server.  Non-transform commands should simply be re-transmitted.  Transform
commands can also be re-transmitted or the client can use the <info> command
to determine the current state of the object.  

Jim  

-----Original Message-----
From: Hollenbeck, Scott [mailto:[email-masked]]
Sent: Wednesday, July 24, 2002 7:14 AM
To: 'Liu, Hong'
Cc: [email-masked]'
Subject: RE: Proposed Document Changes

> beat up the dead horse, but I would like you to clarify the 

I didn't resend it.  Take a look at the message headers -- it looks like
Jaap might have manually approved it for distribution to the list, or
something like that.

> just want to understand it.

This gets back to the "delayed execution" discussion.  If commands don't get
immediate responses, we'd have to have some mechanism in place to let the
client know that commands have been received, but not processed.

> client is allowed to established multiple sessions with the server.

Last command completed, which might not have anything to do with a session.
Remember, the session concept tends to be specific to connection-oriented
transports, and we shouldn't have transport dependencies on generic commands
if they can be avoided.

> after a timeout. EPP ensures idempotency for each command, so 

To be perfectly honest I don't think the <status> command is needed at all.
It got added rather late in the review process when someone asked for the
ability to check on the completion status of a previously executed command
[1].  No one objected when it was discussed on this list back in September
of last year.  I would very much like to ditch the command for the very
reasons you cited.

This is a good time to agree or disagree, folks.  Is the <status> command
really needed or not?

-Scott-

[1]
The thread:
http://www.cafax.se/ietf-provreg/maillist/2001-09/msg00071.html

http://www.cafax.se/ietf-provreg/maillist/2001-09/msg00072.html

http://www.cafax.se/ietf-provreg/maillist/2001-09/msg00074.html

Plus other messages from September 2001, all visible in the archives.