Subject: RE: [NSIS] common signalling application functions (was RE: Tentative Interi m Meeting schedule)

From: [email-masked]
Date: Thu, 29 Apr 2004 13:09:58 +0300

Robert,

> The 2nd approach doesn't sound very different from how Diameter
> was designed, with multiple application support.  Would that
> be a good analogy, or were you thinking of something different?

Rüdiger's mail arrived first, so I didn't see your mail where
you suggested it was Diameter-like ...

Anyhow, I support your suggestion.  Dave, would this address your
concerns at all?

John

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

---

From: David Oran <[email-masked]>
Date: Thu, 29 Apr 2004 12:55:31 -0400

> Anyhow, I support your suggestion.  Dave, would this address your
It solves the pragmatic problems of encoding and abstract syntax, but by 
itself does not ensure that the design of the common functions is in fact 
carefully done with the goal of generality and extensibility across NLSPs.

So, this is progress, yes.

Many of these common functions have impact similar to designing an NLSP 
itself. It would be good if we could tackle them directly with people 
identified to do the work and ensure it meets the needs of the NLSPs we 
know about and that the specification is clean clear, and all that other 
good stuff.

I think we still need further discussion of the related problem of ordering 
among NLSPs so that things like NAT translations and QoS flow classifiers 
work together and don't need multiple RTTs to establish state.

Dave.

---

From: [email-masked]
Date: Fri, 30 Apr 2004 16:24:16 +0200

dear all,

I participated into the design of the AAA in the QoS-NSLP together with
hannes. I tend to agree that this should fall into the so-called 'common
sig app functions' block.

moreover when examinating the dave's list of targetted applications, we
could even narrow the scope of such a common block to AAA (at large...
let's say 'policy'). concerning the design alternative (rüdiger mentions
'toolbox' vs. cross-ref between NSLPs), IMO the first one should lead to
a cleaner design and avoid doing twice the same thing.

I have finally a couple of comments/questions:

1) did you consider integrating such a generic 'toolbox' into GIMPS ? or
maybe the WG wants GIMPS to keep strictly relating to transport ?

I would suggest to copy the RSVP design here: a generic POLICY_DATA TLV
in GIMPS, which contains a list of Policy Element (PE) objects. those
PEs would be designed separately and I'm pretty sure a couple of already
RFCed PEs could even be re-used as is.

2) does the working group think that the design of such generic objects
will come together with some kind of framework ? authz protocols ?
requirements ?

thanks,
yacine

David Oran wrote:

>>> was designed, with multiple application support.  Would that be a
>>> good analogy, or were you thinking of something different?
>> 
>> 
>> Rüdiger's mail arrived first, so I didn't see your mail where you
>> suggested it was Diameter-like ...
>> 
> It solves the pragmatic problems of encoding and abstract syntax, but
> by itself does not ensure that the design of the common functions is
> in fact carefully done with the goal of generality and extensibility
> across NLSPs.
> 
> Many of these common functions have impact similar to designing an
> NLSP itself. It would be good if we could tackle them directly with
> people identified to do the work and ensure it meets the needs of the
> NLSPs we know about and that the specification is clean clear, and
> all that other good stuff.
> 
> I think we still need further discussion of the related problem of 
> ordering among NLSPs so that things like NAT translations and QoS
> flow classifiers work together and don't need multiple RTTs to
> establish state.
> 
> Dave.
> 
> 
>> John
>> 
>> _______________________________________________ nsis mailing list 
>> [email-masked] https://www1.ietf.org/mailman/listinfo/nsis
> 
> 
> 
> 
> 
> 
> _______________________________________________ nsis mailing list 
> [email-masked] https://www1.ietf.org/mailman/listinfo/nsis
>