Marcus Brunner wrote:
>
> Yves,
>
> [...]
>
> > next week, a new version of the sls draft , a framework document and
> > indicative charter will be issued. based on this, we will see how much
> > interest there is to go for a BoF/WG. Since we are a bit late, i will
> > however already contact Bert to ask for a slot in San Diego. So far,
> > from private mails prior to the activation of this list, i have seen
> > quite some interest in specification of this. Also see (
> > http://www.totaltele.com/view.asp?ArticleID=31724&Pub=tt
> > )
>
> I think it is time to go for this now. Iw ill take a lot of time until
> any agreement can be reached.
>
as usual i assume.
> >
> > as for the placing of the draft in the policy framework group : as i
> > tried to explain during the presentation in Pittsburgh, I do agree that
> > there is affinity with the work of the policy framework group, but you
> > don't need the policy framework architecture for supporting the SLS
> > negotiation. In that sense, it is different enough to allow the creation
> > of a different working group.
>
> Look you don't need the Policy Framework WG, on the other hand, the SLS
> handling/negotiation may be very well suited for policy control.
>
it is indeed input to the policy control. Whether this would feed into
the Policy management tool, or directly to the PDP is really an
implementation/deployment detail...
> >
> > how do you mean?
> >
> Again I think the Werner and I have not understand that an SLS can have
> multiple flow-ids (do really want to allow severel flow-ids in an SLS?)
>
i corrected this in the mail to werner. A SLS should have only one flow
id. However, the latter should be capable of aggregating flows
identified by various (combinations) of IP header fields or other.
> the exclusive OR in the list of destination addresses means you can only
> specify a prefix or a host address, but not both of it. But this is not
> a problem if you have severel flow ids.
>
we should indeed be more clear on this, now i understand.
> > > >5. (and also bits of 1.2, etc.)
> > > > The discussion on signaling appears premature and probably beyond
> > > > the scope of a document specifying SLS parameters and semantics.
> > >
> > > I think there should be a requirements draft for the negotiation anyway.
> >
> > I don't know if one can really separate them, since a request for an SLS
> > subscription/invocation may carry a different set of parameters then the
> > ack/offer being presented by the network. we will try to clarify this in
> > our next version.
>
> I think, it should be separated. It is clear that different parameters
> are used in the request and the offer, but both are a service
> specification. I do not doubt, that you need some additional information
> for the negotation process, but this should be handled seperately.
>
we'll try it, and see if it is possible.
thanks again
Yves
This archive was generated by hypermail 2b29 : Mon Oct 16 2000 - 11:40:31 CEST