[NSIS] Comments to QoS NSLP: Policy Elements

[Tschofenig Hannes <hannes.tschofenig at siemens.com>]

hi all, 

reading section a.7.3 (policy elements) i noticed the some issues need to be
changed and hence i suggest to revisit the text in this section. there are a
few questions which came to my mind: 

- should we define our own authorization token format within nsis? there are
already formats for tokens defined. see, for example, 

  Hamer, L-N., Gage, B., Kosinski, B. and H. Shieh, "Session
         Authorization Policy Element", RFC 3520, April 2003.

  Hamer, L-N., Gage, B. and H. Shieh, "Framework for Session
         Set-up with Media Authorization", RFC 3521, April 2003.

  E. T. S. Institute, "Telecommunications and internet protocol
harmonization over networks (tiphon); open settlement protocol (osp) for
inter- domain pricing, authorization, and usage exchange, technical
specification 101 321.  version 2.1.0.

or quite recent work done in sip:

J. Peterson, J. Polk, D. Sicker, H. Tschofenig: "Trait-based Authorization
Requirements for the Session Initiation Protocol (SIP)", (work in progress),
<draft-ietf-sipping-trait-authz-00.txt>, February, 2004

can we reuse them without a major effort from our side. i personally do not
like the osp stuff anymore since it contains much more than we need for
nsis. it is rather an authz token for sip. 

- the only thing the qos nslp needs to worry about is the authorization
attributes which are carried inside the authorization token (e.g., the token
might authorize the holder of the token to make a qos reservation up to
x-y-z kbit/s). these attributes do not need to be specified in the qos nslp.


- if the entity that creates the token also has to verify it then the format
is pretty much irrelevant for nsis (even for the "policy control" engine at
the qos nslp node) if we assume that there is some information which allows
the qos node to send the token to the verifying entity. 

if the "policy control" engine at the qos nslp needs to verify the token by
itself then we have to, at some point in time, specify which is the
preferred token format to provide some interoperability. 

- my impression is that we need to provide a container only for such a token
without specifying its content. there needs to be a type field which tells
the qos nslp (and the "policy control" engine) what type of token it has to
deal with.

- it might be necessary to indicate which entity has to process the token.
this seems to be necessary if the token is requested by a particular entity.
thereby i do not mean, for example the fqdn of the entity that created the
token, but rather a particular nsis node along the path which requested the
token. otherwise the token would be verified by each authz token aware qos
nsis node which happens to see the token.  the consequence would be (a) a
performance impact and (b) probably a rejected reservation since the token
is not understood at some other places. 

ciao
hannes


_______________________________________________
nsis mailing list
nsis at ietf.org
https://www1.ietf.org/mailman/listinfo/nsis