Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt

From: [email-masked]
Date: Fri, 8 Mar 2002 13:33:35 +0200

Hi all,

> > I agree with Roland to a large extent (ie this is too complex). 
> > 
> > I would like the draft to state requirements that the model 
> that should be supproted is: 
> > 
> > - Provider offers a service (describe by some parameters)
> > - Customer buy from this service (described by some parameters) 
> > 
> > Thus a behaviour like: 
> > Provider A: I have service X, Y, Z (described in some way)
> > Customer B: I want b amount of the service X.
> > Provider A: Ok. 
> 
> I don't think we need the service advertisement now (can be an option,
> but is not a requirement). This can be agreed out of nsis. I would
> prefer: if customer requests a service (e.g. identified by a 
> unique ID)
> and if this service is not supported by a provider it rejects the
> requests with a "service not supported" reply.

Thinking about this function, this will be very difficult, because we will
need to create some mechanism to describe services / service offerings.
This is a non-trivial thing to do.  

One way out would be to allow NSIS offerings to be registed in an
IANA registry.  Each NSIS offering would have a value associated 
with it.  If needed, we could allow a query - response method:

Customer: What NSIS offerings do you have:
Provider: I have 1, 3, 8
Customer: I would like 3
Provider: ACK

I don't think we can get more complex than that.

Is this something we want to do in NSIS?

John

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

---

From: Roland Bless <[email-masked]>
Date: Fri, 08 Mar 2002 14:38:22 +0100

Hi John,

> This is a non-trivial thing to do.  

I think my statements were misinterpreted, so let me clarify:
Service descriptions should be defined outside of nsis. There should
only be an agreement on service identification (IANA issue): 
For instance,
Id 1 means standardized service X
Id 645656 means local service Z'
Service X is defined elsewhere to have parameters x.a,x.b,...
So it should not be necessary to propagate service descriptions by 
nsis (because they require interpretation). However, one may advertise 
supported service IDs.

So the scenario would be:
Customer/Provider                  Provider
I want service X with parameter
values
x.a=[l1,u1] and x.b=[l2,u2].
                                   I do not support service X
	                           or
                                   You can use service X with 
                                   x.a=v1 and x.b=v2
 
> I don't think we can get more complex than that.

With the providers advertisement ("I have 1, 3, 8") being optional
and the customers request being "I would like 3 with value x=10",
I would agree on that.

> Is this something we want to do in NSIS?

I don't think we need to negotiate services, but we need to negotiate
service parameter _values_. Is this more clear?

Regards,
 Roland

-- 
Roland Bless -- e-Mail: [email-masked]
Institute of Telematics, University of Karlsruhe, Germany  
Zirkel 2, D-76128 Karlsruhe -- Office: Bld. 20.20, 3rd floor, R 358
Phone: +49 721 608-6413 Fax: +49 721 388097

---

From: Giuseppe Bianchi <[email-masked]>
Date: Fri, 8 Mar 2002 14:40:20 +0100 (MET)

> Customer: What NSIS offerings do you have:

As discussed some time ago, a simpler two-way solution appears to be:

Customer: I want service 8, but can downgrade down to 2
ACK: you receive 3 (providers forward the request and mark downgrades on
it)

This solution can be made more applicable to user's needs by providing a
service description hierarchy, e.g. service class and service level within
the class, i.e:

Customer: I want service class A, level 8 downdradable down to 2
ACK: you receive level 3 within service class A (reject if minimum level
not available within that class).

Regardless of the class, level 0 should be reserved to best effort.

Giuseppe

---
Giuseppe Bianchi
[email-masked]
http://cerbero.elet.polimi.it/people/bianchi