Subject: RE: Capability Negotiation for OCP

From: "Reinaldo Penno" <[email-masked]>
Date: Mon, 21 Apr 2003 10:33:31 -0700

We are having discussions on capability negotiation in the PANA WG also. I
thought on copying their required functionality here to see if we need this
in OCP. PAA and PAC are the peers.

> A)
> 
> Pac <-- Paa: i support x,y and z
> Pac --> Paa: i would like to use y
> 
> B)
> Pac --> Paa: enable x
> Pac <-- Paa: status (ok, failed)
> 
> C)
> Pac <-- Paa: you must use y
> Pac --> Paa: status (ok, failed)
> 
> D)
> Pac --> Paa: what do you support?
> Pac <-- Paa: i support x,y and z

Regards,

Reinaldo

> -----Original Message-----
> From: Alex Rousskov [mailto:[email-masked]] 
> Sent: Monday, April 21, 2003 11:00 AM
> To: [email-masked]
> Subject: RE: Capability Negotiation for OCP
> 
> 
> 
> On Mon, 21 Apr 2003, Abbie Barbir wrote:
> 
> > how about Authentication/Authorization/encrytption.
> >
> > how/when these will be negotiated/supported etc. Are we 
> talking about 
> > another encapsulation (like HTTPS or SASL) here or what?
> 
> It would depend on the transport protocol selection, I think. 
> If the transport protocol already has mechanisms to support 
> Authentication/Authorization/encrytption, then those 
> mechanisms should be reused. IMO, possibility of this kind of 
> reuse would be the primary advantage of selecting an existing 
> application transport (e.g., BEEP) compared to new low-level OCPTRAN.
> 
> Since so many things depend on the transport now, we need to select
> transport(s) as soon as possible.
> 
> Alex.
>

---

From: Alex Rousskov <[email-masked]>
Date: Mon, 21 Apr 2003 12:13:23 -0600 (MDT)

> > Pac <-- Paa: i support x,y and z

These are very similar to what the current OCP draft has. These kind
of questions/answers come from the general "negotiation"
definition/meaning. What you posted on the list a few days ago is,
essentially, a _mechanism_ to implement some (or all) of the above:

	--> let's use x, y, or z
	<-- let's use x OR failure

Specifically, there is virtually no difference between B and C because
"enable" and "use" are pretty much the same verbs in this context.
There is also little difference between A and B because if the "I
support" list is limited to "x", than that option is likely to be
selected/used/enabled. I already asked you a "design" question related
to this little difference: are we negotiating options used by one side
or communication parameters (sued by both sides)? Item D is just a
question of how the dialog is structured.

In short, once you add more specifics to your scheme and answer
already pending questions, we should be able to see wither A-D are
already supported by the mechanism you are working on.

Alex.