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

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

Hi All,

Per my previous email, I've broken the comments down and will reply to them
in separate emails to facilitate my tracking of proposed changes and WG
agreement. My comments below: [MB].

WG feedback on this would be appreciated prior to 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.7 - I can't quite see how this goes from F to P+; you'll need to
> provide more text or clarification.
>

RSIP ASSIGN_RESPONSEs to successful ASSIGN_REQUESTs include a bindID
parameter that uniquely identifies the binding (read "ruleset"). The
bindID is specified in subsequent requests, e.g., EXTEND_REQUEST to
extend the lease time of a binding, to identify the binding to which
the request is to apply.

I believe the RSIP specification intended, though never explicitly stated,
that further requests on a binding be restricted to the to the host that
created the binding; although once again, one might say that that is a
matter of installation policy. To clearly satisfy the MIDCOM requirements,
the RSIP semantics would be explicitly extended to permit any authorized
host to request operations on a binding.

As to text to use in the evaluation document, I would suggest:

     RSIP does not explicitly either permit or preclude an operation on
     a binding being requested by a host other that the host that created
     the binding. The RSIP semantics would need to be explicitly extended
     to permit any authorized host to request operations on a binding. No
     change to the protocol would be required.

[MB] I can see that we could change RSIP to P for this one based upon the
text.  I think this makes it consistent with the Megaco and COPS evaluations
of this requirement.  Per my note below, the Diameter issue is being tracked
in a separate email thread.

I would propose the following re-wording for the text:

" RSIP neither explicitly permits nor precludes an operation on a binding by
a host that had not originally create the binding. However, to support this
requirement, the RSIP semantics must be extended to explicitly permit any
authorized host to request operations on a binding; this does not require a
change to the protocol."
[/MB]

BTW, since the "The diameter protocol as currently defined offers no
impediment [to] such an operation." and is scored a T, maybe either RSIP
should be scored a T or DIAMETER should also be scored a P+?

[MB] This is being tracked in a separate email thread per my response to
your original email.  If you still have concerns that this requirement also
has a semantic impact on Diameter, please post them in response to that
email thread. 
[/MB]

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