Subject: [midcom] Protocol eval: 2.2.1 RSIP - proposal to change score

From: [email-masked]
Date: Mon, 5 Aug 2002 13:28:01 -0500

Middlebox experts,

As I have said in a previous e-mail, RSIP clearly was designed to be
extensible. The evaluation text of RSIP for this requirement explains
how this works in more detail than the evaluation text for the other
protocols.

RSIP is currently scored a P+ on this requirement when it should, in
my opinion, clearly be a T: it has a degree of extensibility comparable
to the other protocols, and they were scored a T.

I propose that the score of RSIP for this requirement be changed to T.
I don't think there's any need to change the expanatory text.

Comments expected and welcome.

Jim

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

---

From: "Cedric Aoun" <[email-masked]>
Date: Tue, 6 Aug 2002 20:16:01 +0200

If we want to be honest with other protocol evaluations,
I don't see how RSIP's extensibility mechanisms would be graded in the same
way as the other evaluated protocols.
The other protocols have extensibility mechanisms were the base protocol
messages
are not always required to be extended to include new parameters (or even to
create new messages).
The other protocols use a certain "envelop" where the application (in this
case Middlebox control) 
specific properties are contained, this provides a better extension
mechanism than the RSIP protocol.
IMHO I don't think we should grade RSIP to T, to be fair it has to have a
lower grade than
the other protocols.
Cedric

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 05 August 2002 20:28
To: midcom
Subject: [midcom] Protocol eval: 2.2.1 RSIP - proposal to change score

Middlebox experts,

Jim

---

From: [email-masked]
Date: Tue, 6 Aug 2002 22:29:14 -0500

Bob,

Thanks for pointing this out. I didn't even think of this last night as
I was rushing out responses.

Jim

"Bob Penfield" <[email-masked]>@ietf.org on 08/06/2002 01:57:21
PM

Sent by:  [email-masked]

To:   "Tom-PT Taylor" <[email-masked]>, "Cedric Aoun"
      <[email-masked]>, James Renkel/MW/US/3Com,
      <[email-masked]>
cc:
Subject:  Re: [midcom] Protocol eval: 2.2.1 RSIP - proposal to change score

I have to note that RSIP does include an extensibility mechanism defined in
section 12 of RFC 3103:

  All of the designations below have been registered by the IANA.

      -  RSIP port number: 4555
      -  RSIP error codes (see Appendix A).
      -  RSIP message type codes (see Appendix B).
      -  RSIP tunnel types, methods, and flow policies.

   RSIP parameter values are designated as follows:

      -  0       Reserved
      -  1-240   Assigned by IANA
      -  241-255 Reserved for private use

   New registrations for the above namespaces are recommended to be
   allocated via the Specification Required method documented in
   [RFC2434].

I agree that it is the least extensible, but it is extensible.

----- Original Message -----
From: "Tom-PT Taylor" <[email-masked]>
To: "Cedric Aoun" <[email-masked]>;
<[email-masked]>;
<[email-masked]>
Sent: Tuesday, August 06, 2002 2:40 PM
Subject: RE: [midcom] Protocol eval: 2.2.1 RSIP - proposal to change score

>
> To summarize, you are saying that some protocols (most, in fact) have
> explicit extensibility mechanisms, where others (RSIP in particular) do
not.
>
> If I were to rank the candidates by readiness for extensibility this is
how
> I would see it.  I omit COPS because I'm not familiar with it, and I'm
> taking risks with RSIP because I'm not really familiar with it either:
>
> SNMP (most extensible): extensions require absolutely no change to the
> protocol itself.
>
> DIAMETER: extension mechanism provided, does mean protocol changes, but
> extensions can be handled by other DIAMETER entities without being
> understood.  (Actually not sure that this property is relevant or useful
in
> the MIDCOM case.)
>
> MEGACO: extension mechanism provided, does mean protocol changes, both
ends
> have to understand the extensions.
>
> RSIP: no formal extension mechanism; extensions have to be designed into
the
> protocol from scratch.
> From: Aoun, Cedric [GOLF:MA01:EXCH]
> Sent: Tuesday, August 06, 2002 2:16 PM
> To: [email-masked]'; [email-masked]'
> Subject: RE: [midcom] Protocol eval: 2.2.1 RSIP - proposal to change
score

---

From: [email-masked]
Date: Tue, 6 Aug 2002 22:19:52 -0500

Tom & Cedric,

The other protocols have a different extension "philosohy" than does
RSIP. To extend the others ya design MIBs, packages, etc. Let's call
that the "package philosophy". To extend RSIP, ya add messages, add
parameters to messages, add new values to parameters, etc. Let's call
that the "non-package philosophy". To my mind, they are both perfectly
valid extension philosophies.

While the package philosophy may be more appropriate than the non-
package philosophy in certain situations, I think the opposite is also
true.

I think the non-package philosophy generally produces smaller, in total
size, i.e., the size of of the base plus the size of the extension,
protocols and implementations than the package philosophy, while the
package phiosophy might produce smaller incremental size, i.e., just
the size of the extension. I think that sometimes it might even be the
case that the total size using the non-package philosophy could be
smaller than just the extension using the package philosophy.

Now, if I've already got the base protocol (SNMP, MEGACO, etc.)
implementented in the environment to which I want to add middlebox
control, then the package philosophy might be preferred. But if I don't
already have the base protocol implemented, then I've got to add it
before I can even consider adding the extension, and the non-package
philosophy might be preferred.

Vendors of small SOHO access routers that include firewall or NAT
technology have expressed concern to me about the size of, e.g., MEGACO.
For SIP phones, I've been told that. e.g., MECAGO isn't even a
consideration. But both have successfully implemented RSIP, and have
been delighted with it's small size.

Of course implementation size is only one factor that needs to be
considered: development time; test time; etc. But again, those differ
depending on whether I've just got to add the extension or I've got to
add the base before I can add the extension.

Unfortunately, the analysis isn't as simple as we'd like it to be, and
I don't think one analysis can fit all cases.

Jim

"Tom-PT Taylor" <[email-masked]>@ietf.org on 08/06/2002 01:40:07
PM

To:   "Cedric Aoun" <[email-masked]>, James
      Renkel/MW/US/3Com, "'midcom @ietf.org'" <[email-masked]>
cc:
Subject:  RE: [midcom] Protocol eval: 2.2.1 RSIP - proposal to change score

If I were to rank the candidates by readiness for extensibility this is how
I would see it.  I omit COPS because I'm not familiar with it, and I'm
taking risks with RSIP because I'm not really familiar with it either:

DIAMETER: extension mechanism provided, does mean protocol changes, but
extensions can be handled by other DIAMETER entities without being
understood.  (Actually not sure that this property is relevant or useful in
the MIDCOM case.)

MEGACO: extension mechanism provided, does mean protocol changes, both ends
have to understand the extensions.

-----Original Message-----
From: Aoun, Cedric [GOLF:MA01:EXCH]
Sent: Tuesday, August 06, 2002 2:16 PM
To: [email-masked]'; [email-masked]'
Subject: RE: [midcom] Protocol eval: 2.2.1 RSIP - proposal to change score

are not always required to be extended to include new parameters (or even
to
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 05 August 2002 20:28
To: midcom
Subject: [midcom] Protocol eval: 2.2.1 RSIP - proposal to change score

Middlebox experts,