Subject: Re: [midcom] Re: draft-renkel-rsip-midcom-eval-00.txt

From: [email-masked]
Date: Fri, 10 May 2002 14:40:28 -0500

Joel,

Thank you for your comments on the evaluation of RSIP against the
MIDCOM requirements. I did not respond to your comments earlier
because I expected more comments and hoped to possibly respond to
them all at once.

Since yours are the only comments I received, I'll respond to all the
comments I received all at once! :-)

>    My primary observation reading this document is that it would be
>    helpful if you clearly and early in the document indicated that
>    your proposal is to change the data handling behavior of te
>    middlebox.

It is NOT my intention to change the data handling behavior of the
middlebox. The intention of the I-D was to show how RSIP could be
extended to cover middleboxes that are different from what RSIP anti-
cipated when it was designed.

>    If this is not your intent, then significant attention is needed
>    to how RSIP would work without the currently required tunneling
>    (you merely say "null tunnel", but there is a lot more to it than
>    that.

Yes and no. When I worked through the design of a "null" tunnel, it fit
into RSIP very nicely and allowed RSIP to satisfy the MIDCOM require-
ments as stated in the I-D. However, it also exposed a number of issues
that I don't think are adequately addressed by the MIDCOM requirements.
Maybe they are addressed, but I just don't see them. I could be wrong.

Yes, I owe everybody a description of a "null" tunnel, how it would
work, how RSIP then satisfies the MIDCOM requirements to the extent
claimed in the evaluation I-D. I am preparing that as a separate I-D
that also raises the other issues I think I have found. I should have
that in a few weeks, hopefully before the cut-off for the Yokahama
meeting.

>    The other issue is that as I understand it RSIP as currently
>    designed assumes that the requestor and the communicating party
>    are one and the same.  If this is so, and is a behavior you intend
>    to retain, please say so.  If it is a behavior you believe can be
>    changed, then some description of the complications and degree of
>    change to RSIP would be helpful.

I wouldn't say that "RSIP ... assumes that the requestor and the communi-
cating party are one and the same", it's more that it didn't admit to the
possiblity that they might not be the same. Subtle, but important, dis-
tinction.

That said, what happens to RSIP if the application and the agent aren't
the same? I guess that depends on your reading of the RSIP specification,
as this is now a gray area not addressed by the specification. In check-
ing this with some of my colleagues, we have found a way to read the
specification that would allow the behavior intended by the MIDCOM
requirements. But it's such a weird, obscure, perverse, etc., reading
that I wouldn't propose it as "the right thing to do."

So, yes, RSIP should be revised to explicitly account and allow for
agents as well as applications. This change is really simple: if a client
isn't "speaking for itself", then it identifies the client for which it
is speaking. All it takes is one (maybe a few) additional parameters in
the relevant RSIP messages. Extremely easy to do, with full backward com-
patibility, because RSIP was designed to be extensible, in exactly this
way!

BTW, it was when we were exploring this "agent vs. application" issue
that we discovered the other issues I mentioned above. Again, maybe they
really aren't issues, or they are issues that have already been addressed,
but I'll raise them anyhow in the new I-D.

I have revised the evaluation I-D, hopefully addressing the issues you
raised. The changes are basically what I described above.

Again, thank you for your comments.

Jim

_______________________________________________
midcom mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/midcom