Subject: RE: [midcom] Protocol eval: 2.2.9 RSIP - proposal to change score and text

From: "Cedric Aoun" <[email-masked]>
Date: Tue, 6 Aug 2002 18:30:10 +0200

I initially understood the P+ category as the protocol could be extended by
using
the defined extensibility mechanisms without changing the base protocol
messages.
This is main difference between P and P+.
Other protocols evaluated in this process have MIBs, PIBs, packages etc ...
to be extended
easily.
IMO RSIP fails to meet this requirement as you just stated that RSIP does
not guarantee
preservation of port number oddity; and it doesn't have easy extensibility
tools it requires
new messages or new parameters within the base protocol messages.It should
actually be an F.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 06 August 2002 00:05
To: midcom
Subject: [midcom] Protocol eval: 2.2.9 RSIP - proposal to change score
and text

Middlebox experts,

As I have said in a previous e-mail, RSIP can easily be extended to
preserve port number oddity when creating bindings. RSIP currently does
not guarantee preservation of port number oddity.

RSIP would add a new optional boolean parameter called portOddity to the
ASSIGN_REQUESTs. If specified as TRUE, the remote port number of the
binding created would have the same oddity as the local port. If not
specified (or specified as FALSE), the remote port's oddity is independent
of the loacl port's oddity, thus maintaining backward compatibility with
the current definition of RSIP.

RSIP is currently scored a P on this requirement when it should, in
my opinion, clearly be a P+.

I propose that the score of RSIP for this requirement be changed to P+,
and the text changed to:

     RSIP can be extended to preserve the port number oddity of a
     binding by including an optional boolean portOddity parameter
     on ASSIGN_REQUESTs. If specified as TRUE, the remote port number
     of the binding created would have the same oddity as the local port.
     If not specified (or specified as FALSE), the remote port's oddity
     is independent of the local port's oddity, thus maintaining
     backward compatibility with the current definition of RSIP.

Comments expected and welcome.

Jim

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

---

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

----- Original Message -----
From: "Cedric Aoun" <[email-masked]>
To: <[email-masked]>; "midcom" <[email-masked]>

> I initially understood the P+ category as the
> protocol could be extended by using the defined
> extensibility mechanisms without changing the base protocol
> messages. This is main difference between P and P+.
> Other protocols evaluated in this process have MIBs,
> PIBs, packages etc ... to be extended easily.
> IMO RSIP fails to meet this requirement as you just stated
> that RSIP does not guarantee preservation of port number
> oddity; and it doesn't have easy extensibility tools it
> requires new messages or new parameters within the
> base protocol messages.It should actually be an F.
>

I'm afraid I have to disagree. The IANA Considerations section of RFC 3103
allows for defining new parameters, error codes, message type codes, etc.
There is no need to change the base protocol messages. I see very little
difference between defining a new RSIP parameter for port-oddity and a new
Megaco property for port-oddity in a new midcom package. Both require new
behaviour by the middlebox.