Subject: [midcom] Protocol Eval: 2.2.2 - RSIP (was RE: Proposed changes to RSIP ev aluation

From: "Mary Barnes" <[email-masked]>
Date: Mon, 5 Aug 2002 15:52:19 -0500

Hi all,

I don't have a problem changing 2.2.2 for RSIP to P+, IFF there is agreement
by the WG to change 2.2.1 Extensibility to T for RSIP. However, we've
already spent some time debating 2.2.2 for Megaco (refer to the email
threads with 2.2.2 in the title) and finally agreeing on T.  As well, we've
previously discussed SNMP, with agreement that it is a T.  And to a lesser
extent, there has also been discussion on COPS.

Again, I don't think we should revert these previous agreements unless there
is additional support to do so.  

Again, WG feedback by COB Tuesday, August 6th is appreciated.

Regards,
Mary. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Sunday, August 04, 2002 10:42 PM
To: 'midcom'
Subject: Re: Proposed changes to RSIP evaluation (was RE: [midcom]
Comments on protocol evaluation draft

---text deleted -----

>
> 2.2.2 - I think a P+ needs additional text to substantiate that this
> would be a compatible extension of the protocol (OR we need some text
> upfront in the RSIP overview describing the extensibility mechanisms
> defined by RSIP)
> 2.2.3 - ditto
>

Since, in recent semantics discussions, I believe we have agreed that
the only ruleset action needed is permit, the statement in the text may
be true as it stands.

If it is desirable to include some kind of parameter that indicates the
type of middlebox being manipulated (NATter, firewall, VPN tunnel switch,
etc.), that certainly can added, and in a completely backward compatible
way. As I read the text for SNMP and COPS, they seem to imply that they
already have this parameter, and therefore deserve a T (But more on this
later.).

The MEGACO text says multiple middlebox types can be supported when you
define the middlebox package for MEGACO, and is scored a T. But an
extension to MEGACO (i.e., one or more new packages) is required, so I
think this ought to be a P+ (presumably it can be done with backward
compatibility).

The DIAMETER text says an extension is necessary, and is scored a P, now
presumably a P+.

But if ya look at the MIDCOM requirements (I'm looking at the -05
draft.), it says under requirement 2.2.2:

     This states that a the protocol must support rules and actions for
     a variety of types of middleboxes.

According to this as I read it, just having a parameter that
distinguishes among types of middleboxes isn't suffucient, ya gotta have
rules and actions already defined in the protocol to justify a T score.
I don't think this is the case for any of the protocols (Although RSIP
probably comes the closest: it does have the notion of rules defined; not
actions, but they may not be needed anymore.), so I think the T scores for
SNMP and COPS should also be P+.

Again, I'm looking for consistency here. All require extension, so all
should be graded the same, and I think that's a P+.

If the question had simply been "Can ya already distinguish between
multiple middlebox types?", then the T scores for SNMP and COPS would be
justified.
---Remaining text deleted ----

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