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

From: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 6 Aug 2002 14:40:07 -0400

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.

-----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

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, 
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 

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

---

From: "Bob Penfield" <[email-masked]>
Date: Tue, 6 Aug 2002 14:57:21 -0400

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