Subject: [midcom] RE: Protocol Eval - 2.2.8, 2.2.9 and 2.2.11 - RSIP and others (w as RE: Proposed changes to RSIP evaluation....

From: "Mary Barnes" <[email-masked]>
Date: Mon, 5 Aug 2002 13:07:45 -0500

Hi all,

I'm going to respond to a few of these requested changes for RSIP for 2.2.8,
2.2.9 and 2.2.11, and comments on the other protocols, directly inline here.
The remainder I am going to post separtely so that they can be tracked more
easily, thus, I've deleted most of Jim's original email.

Feedback on these proposed changes is requested by noon CST on Tuesday,
August 6th.  

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.8 - I think a P+ needs additional text to substantiate that this
> would be a compatible extension of the protocol
>

RSIP would add a new optional enumeration parameter called
transportProtocol to the ASSIGN_REQUESTs. If specified, the binding
created would apply only to the use of the bound addresses / ports by the
specified transport protocol. If not specified, the binding would apply to
all use of the bound addresses / ports by any transport protocol, thus
maintaining backward compatibility with the current definition of RSIP.

[MB] I propose to add the following text (reworded for consistency) to RSIP
and change to a P+:

"To support this requirement, a new optional enumeration parameter,
transportProtocol, can be added to the RSIP ASSIGN_REQUESTs.  When the
parameter is included, the binding created applies only to the use of the
bound addresses and ports, by the specific transportProtocol. When the
parameter is not included, the binding applies to the use of all the bound
addresses and ports, by any transport protocol, thus maintaining backward
compatibility with the current definition of RSIP." 
[/MB]

BTW, MEGACO is scored a T on this requirement for a package that isn't
yet defined. :-(

[MB] Yes, this was the one issue, that I acknowledged in response to your
original email, that I thought was valid, thus I had posted separately and
we have agreed to change MEGACO to a P+.
[/MB]

>
> 2.2.9 - I don't have a problem with changing this to P.  Again, P+ would
> require additional text to substantiate that this would be a compatible
> extension of the protocol.
> 2.2.11 -ditto
>

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.

[MB] I propose to add the following text (reworded for consistency) to RSIP
and change to a P+:

"To support this requirement, a new optional boolean parameter, portOddity,
can be added to the RSIP ASSIGN_REQUESTs.  If the parameter is TRUE, the
remote port number of the binding created would have the same oddity as the
local port. If the parameter is not specified, or is FALSE, the remote
port's oddity is independent of the local port's oddity, thus maintaining
backward compatibility with the current definition of RSIP." 
[/MB]

BTW, MEGACO is again scored a T on this requirement for a package that
isn't yet defined. :-(

[MB] The version of the document that I have already shows Megaco as a P+
for 2.2.9, as well as 2.2.11.
[/MB]

Overlapping rulesets may have gone away with recent semantics discussions,
but ...

RSIP would add a new optional boolean parameter called overlapOK to the
ASSIGN_REQUESTs. If specified as TRUE, the binding created may overlap with
another existing binding. If not specified (or specified as FALSE), the
binding will only be created to not overlap with an existing binding, thus
maintaining backward compatibility with the current definition of RSIP.

[MB] I propose to add the following text (reworded for consistency) to RSIP
and change to a P+:

"To support this requirement, a new optional boolean parameter, overlapOK,
can be added to the RSIP ASSIGN_REQUESTs.  If the parameter is TRUE, the
binding may overlap with an existing binding. If the parameter is
unspecified, or is FALSE, the binding will not overlap with an existing
binding, thus maintaining backward compatibility with the current definition
of RSIP." 
[/MB]

For this requirement, I believe MEGACO was correctly scored as a P+.

Whew! I think that addresses all of Mary's response.

Commented 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