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

From: "Mary Barnes"<[email-masked]>
Date: Wed, 22 May 2002 14:11:06 -0500

Jim,

Well, it looks like your objective for the the first draft isn't necessarily
specific to describing RSIP as applicable to the MIDCOM protocol, so I don't
think it needs to be included as part of the MIDCOM protocol evaluation
document. 

Mary.  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, May 22, 2002 1:23 PM
To: Barnes, Mary [NGC:B601:EXCH]
Cc: [email-masked]
Subject: RE: [midcom] Re: draft-renkel-rsip-midcom-eval-00.txt

Mary,

I am intending to submit two I-Ds before the Yokahama meeting, approxi-
mately entitled:
1. NATs, tunnels, and the MIDCOM protocol; and
2. Requirements for supporting middleboxes in session control protocols.

At this time, I see no problem with having the first one by 6/14/2002,
so that it can be discussed via e-mail and then included as an appendix
of the evaluation document.

I'll follow with the second one ASAP after the first.

Let me know if this is what you're looking for. Or not.

Jim

"Mary Barnes"<[email-masked]> on 05/22/2002 12:10:05 PM

Sent by:  "Mary Barnes"<[email-masked]>

To:   James Renkel/MW/US/3Com
cc:
Subject:  RE: [midcom] Re: draft-renkel-rsip-midcom-eval-00.txt

Jim,

I'm in the middle of pulling the document together for Friday's deadline
and
was just doing a double-check that all email comments were fully
incorporated and realized that I hadn't read your email in detail and I do
have some questions wrt to your "null" tunnel-id as it appears you're
proposing to have that available by June 21st (which is the Yokohama
deadline for -00 drafts).  The current timeline for the protocol evaluation
draft would be to have the document ready for WGLC by June 28th.  I think
it
would be extremely useful to have this information included as an appendix
for the protocol evaluation draft (which is what I'm planning on doing with
the appendix which is now in the Megaco draft).  Is there anyway you could
have that available for discussion by June 14th so that we can have mailing
list discussion about including it in the appendix of the protocol
evaluation document due out on the 28th?

Given the level of interest and discussion these drafts have had on the
mailing list, I think this is achievable, but understand you may have other
constraints that I haven't considered.  We do have some leaway, however, I
had really wanted to have a fairly close to final version submitted prior
to
Yokohama so indeed if anyone had any issues they could be discussed during
the session.  So, I think that even if you can't get your draft out prior
to
the 21st, we could still discuss including this in the protocol evaluation
document in Yokohama.

Regards,
Mary H. Barnes
[email-masked]
972-684-5432
Wireless 817-703-4806

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, May 10, 2002 2:40 PM
To: Joel M. Halpern
Cc: [email-masked]
Subject: Re: [midcom] Re: draft-renkel-rsip-midcom-eval-00.txt

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

(See attached file: C.htm)