Subject: [Dime] Clarification on Auth Server state machine

From: "Balamurugan T, TLS-Chennai" <[email-masked]>
Date: Wed, 23 May 2007 20:55:20 +0530

Hi All,

As per RFC3588, The diameter server will send the RAR request to diameter client.But, In AUTH SERVER state machine

there is no state table entry to send  Service specific requests from server. Also Sh,GqGo interfaces send some request

messages  from server.

Can you please clarify this contradiction in RFC.

Regards,

Bala

DISCLAIMER:
-----------------------------------------------------------------------------------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only.
It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in 
this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates.
Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of 
this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have
received this email in error please delete it and notify the sender immediately. Before opening any mail and 
attachments please check them for viruses and defect.

-----------------------------------------------------------------------------------------------------------------------

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

---

From: Victor Fajardo <[email-masked]>
Date: Wed, 23 May 2007 12:14:11 -0400

Hi,

>     As per RFC3588, The diameter server will send the RAR request to 
> diameter client.But, In AUTH SERVER state machine
>     there is no state table entry to send  Service specific requests 
> from server. Also Sh,GqGo interfaces send some request
>

Maybe we can separate your comments into two(2). First, RARs are not 
depicted in the stateful auth fsms. This should probably be fixed if 
this is the case. Second, I'm not sure that we should not consider RAR 
as "service specific requests". AFAIK, service specific request sent 
from the server is currently not allowed unless the server entity is 
generating a diameter client session. There are ongoing discussions 
about this topic in other threads (Qos).

regards,
victor

> ------------------------------------------------------------------------
>
> DISCLAIMER:
> ------------------------------------------------------------------------
>

---

From: "Miguel A." Nuñez <[email-masked]>
Date: Tue, 29 May 2007 14:17:56 +0200

Hi,

I have checked auth stateful server fsm at rfc 3588 and in fact it does
not allow to send service specific requests. 

Checking the auth stateless server fsm, it neither allows to send
service specific requests. This is a bit surprising because i.e. Sh
interface servers, that work in stateless mode, can send PNR requests.

This seems to be against the spirit of diameter being a peer-to-peer
protocol from a transport point of view. Although peers are simetric
from a transport point of view, servers cannot send requests (except ASR
as per the fsm). And more, there is a contradiction between RFC 3588 and
some 3GPP specs.

Victor, do you know if there are plans to modify the fsms in the new
drafts evolving rfc3588?

regards,
Miguel Angel

---

From: Victor Fajardo <[email-masked]>
Date: Tue, 29 May 2007 09:17:53 -0400

Hi Miguel,

Comments inline:

>
> I have checked auth stateful server fsm at rfc 3588 and in fact it 
> does not allow to send service specific requests.
>
> from a transport point of view, servers cannot send requests (except 
> ASR as per the fsm). And more, there is a contradiction between RFC 
> 3588 and some 3GPP specs.

I guess we can also consider diameter as a two(2) part protocol where 
the peer fsm is the peer-to-peer part and the sessions fsm is the 
client/server application part. The current discussion is focused more 
on the session fsm part so we can separate the "peer-to-peer transport" 
aspect and not use its current behavior as a justification to change the 
session fsm side.

The current session fsm seems to function in a traditional client/server 
way where application specific conversations are always client 
initiated. I cannot speak for why 3GPP or other apps does not follow 
this and they may gave good technical reasons for doing so. In any case, 
we can probably sub-divide the discussion into two(2) issues (this 
includes discussions in other threads):

1. where the first app specific exchange is initiated by the server - I 
still have doubts about this since this maybe solved by other means such 
as having the "application server" create diameter client sessions to 
initiate a conversation.
2. where subsequent app specific exchanges are initiated by the server - 
this maybe acceptable in stateful sessions where applications may need 
similar msg exchange behavior like RAR. However, for stateless sessions, 
this not applicable and solutions becomes similar to (1).

I hope more folks can add their input to this so we can move forward 
more quickly on this issue.

best regards,
victor

---

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 29 May 2007 09:51:45 -0400

Hi Victor/Manuel,

Please see below for comments.

   Thanks,
   Tolga

> -----Original Message-----
> From: Victor Fajardo [mailto:[email-masked]]
> Sent: Tuesday, May 29, 2007 9:18 AM
> To: "\"Miguel A.\" Nuñez"
> Cc: [email-masked]
> Subject: Re: [Dime] Clarification on Auth Server state machine
> 
> Hi Miguel,
> 
> Comments inline:
> 
> >
[TOLGA]I completely agree with this approach. Furthermore, we should consider that Diameter base protocol functionality is used by many different applications. Some of these are using Diameter as a transport mechanism. IMHO, there is nothing wrong with that. Diameter base protocol provides a nice networking layer and a mechanism to carry different types of data in an efficient manner. So, it actually is a really good choice. OTOH, using Diameter base protocol in such a way means that an application, which is not an authentication/authorization application per se, should define its own state machine rules. 3GPP Sh interface is a good example for that. It is used to download/update user profile between CSCF/HSS. The expected behavior is defined in relevant 3GPP specifications, so I don't see why that message exchange should be compliant with authentication/authorization state machine defined in RFC3588. Similarly, I even don't see why it shouldn't be possible to extend/modify authentication/authorization state machines defined in RFC3588 in a different document, e.g. a 3GPP specification, as long as this is a different application with a unique Application-Id.
> as having the "application server" create diameter client sessions to
[TOLGA]I agree with this one as well. It is possible I am missing something, but somebody should explain with an example why this is technically such a bad thing.
> this not applicable and solutions becomes similar to (1).
[TOLGA]Agreed.

---

From: "Miguel A." Nuñez <[email-masked]>
Date: Wed, 30 May 2007 13:17:16 +0200

Hi Victor,

Ok. Let's try to move forward.

Let me first explain the sh case. I don't want to turn this into a 3gpp
issue, but just use this case as an example of an application that uses
the services provided by diameter base. We can try to discuss about the
flexibility of diameter based on this example.

Sh interface allows an AS to subscribe to modifications of a user's
profile at the HSS. The dialogue begins by sending SNR, so AS gets
subscribed to any specific field modifications. Whenever that
modification happens, HSS sends PNR to notify about it. In all this
scenario, by the moment, we will consider HSS is a diameter server and
AS is a diameter client.

Now please see my comments below, having in mind this use case.

Best regards,
Miguel Angel

> aspect and not use its current behavior as a justification to change the 

[MIG] I agree.

> this not applicable and solutions becomes similar to (1).

[MIG] The sh case fits well in the stateful model. All subscription
messages are related to the same user, so it seems the most logic way to
have all them into the same diameter session.

If we try to create diameter client sessions, it implies to have the HSS
acting first as diameter server and afterward as diameter client,
creating a new session for a message exchange completely related to the
previous one. You will have two sessions mixed all along the
subscription duration (the subscription ends by sending another SNR that
should be in the same session as the first SNR), being both sessions
related to same subscription. Not a nice way to do things.

In practice, this subscription dialogues can last for days, even months.
>From an implementation point of view, you get almost obliged to use a
stateless mode. And taking into consideration the other message
exchanges that can happen at sh interface (UDR and PUR), they are
profile downloads and updates, so it makes sense to do both in stateless
mode. As a result, the whole sh becomes stateless, even if subscriptions
should be stateful from a pure conceptual point of view.

I would like diameter to be flexible enough to fit for this kind of
applications, and allow servers to send requests at least in stateful
mode. It would be even greater to have a completely flexible protocol
that allows transaction exchanges whenever applications need them. There
are protocols that work in this way. I can see that sh is not the only
case (checking ITU-T Liason at
http://www.tschofenig.priv.at/twiki/bin/view/Dime/IetfDimeRoadMap)

Someone should really explain me why it is so great to have a session
layer with the limitations of a client-server model, when having
available a great tranport layer without them.

I would really like to see a list of advantages related to the
client-server model. If folks provide good reasons, I will be more than
happy to recognize that it is the model that better fits. In any case, I
encourage folks to discuss models providing maximum flexibility.

---

From: <[email-masked]>
Date: Wed, 30 May 2007 15:09:25 +0300

Hi,

> [MIG] The sh case fits well in the stateful model. All 
> subscription messages are related to the same user, so it 
> seems the most logic way to have all them into the same 
> diameter session.

> In practice, this subscription dialogues can last for days, 
> even months. From an implementation point of view, you get 
> almost obliged to use a stateless mode. And taking into 
> consideration the other message exchanges that can happen at 
> sh interface (UDR and PUR), they are profile downloads and 
> updates, so it makes sense to do both in stateless mode. As a 
> result, the whole sh becomes stateless, even if subscriptions 

FYI, Sh spec 3GPP TS 29.329 states:
  "Whenever the definition and use of an AVP is not specified
   in this document, what is stated in 3GPP TS 29.229 [6] shall
   apply."

3GPP TS 29.229 in turn states:
  "The client (server) shall include in its requests
   (responses) the Auth-Session-State AVP set to the value
   NO_STATE_MAINTAINED (1), as described in IETF RFC 3588 [6]."

So if you feel you need to clarify the state-machines in
IETF RFC 3588 for the purposes of 3GPP Sh interface functionality,
it would seem that the relevant state-machines in 3588 for Sh are
'CLIENT, STATELESS' and 'SERVER, STATELESS'.

On the other hand, do we need to define a state machine at
all for supposedly stateless operation?

Best Regards,
Mikko Aittola

> From: ext Nuñez [mailto:[email-masked]] 
> Sent: 30 May, 2007 14:17
> To: Victor Fajardo
> Cc: [email-masked]
> Let me first explain the sh case. I don't want to turn this 
> into a 3gpp issue, but just use this case as an example of an 
> application that uses the services provided by diameter base. 
> We can try to discuss about the flexibility of diameter based 
> on this example.
> 
> Sh interface allows an AS to subscribe to modifications of a 
> user's profile at the HSS. The dialogue begins by sending 
> SNR, so AS gets subscribed to any specific field 
> modifications. Whenever that modification happens, HSS sends 
> PNR to notify about it. In all this scenario, by the moment, 
> we will consider HSS is a diameter server and AS is a diameter client.
> 
> [MIG] The sh case fits well in the stateful model. All 
> subscription messages are related to the same user, so it 
> seems the most logic way to have all them into the same 
> diameter session.
> 
> If we try to create diameter client sessions, it implies to 
> have the HSS acting first as diameter server and afterward as 
> diameter client, creating a new session for a message 
> exchange completely related to the previous one. You will 
> have two sessions mixed all along the subscription duration 
> (the subscription ends by sending another SNR that should be 
> in the same session as the first SNR), being both sessions 
> In practice, this subscription dialogues can last for days, 
> even months. From an implementation point of view, you get 
> almost obliged to use a stateless mode. And taking into 
> consideration the other message exchanges that can happen at 
> sh interface (UDR and PUR), they are profile downloads and 
> updates, so it makes sense to do both in stateless mode. As a 
> result, the whole sh becomes stateless, even if subscriptions 
> I would like diameter to be flexible enough to fit for this 
> kind of applications, and allow servers to send requests at 
> least in stateful mode. It would be even greater to have a 
> completely flexible protocol that allows transaction 
> exchanges whenever applications need them. There are 
> protocols that work in this way. I can see that sh is not the 
> only case (checking ITU-T Liason at 
> Someone should really explain me why it is so great to have a 
> session layer with the limitations of a client-server model, 
> when having available a great tranport layer without them.
> 
> I would really like to see a list of advantages related to 
> the client-server model. If folks provide good reasons, I 
> will be more than happy to recognize that it is the model 
> that better fits. In any case, I encourage folks to discuss 
> models providing maximum flexibility.

---

From: <[email-masked]>
Date: Wed, 30 May 2007 15:09:25 +0300

Hi,

Best Regards,
Mikko Aittola

---

From: "Asveren, Tolga" <[email-masked]>
Date: Wed, 30 May 2007 08:29:27 -0400

First of all, why does Sh use authorization state machine as defined in RFC3588? There should have been a state machine defined specifically for Sh. They probably thought that the existing authentication state machine is similar to what they need. 

I think, people should understand that if they define a new Diameter application, and if that Diameter application is not an extension/similar to an existing application (whose state machine they can borrow), they need to define a state machine/semantics for it. If there is a need for change, it is the corresponding 3GPP document IMHO.

    Thanks,
    Tolga 
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, May 30, 2007 8:09 AM
> To: [email-masked]; [email-masked];
> [email-masked]
> Subject: RE: [Dime] Clarification on Auth Server state machine
> 
> Hi,
>

---

From: "Miguel A." Nuñez <[email-masked]>
Date: Wed, 30 May 2007 14:52:47 +0200

Hi Mikko,

See inline.

best regards,
Miguel Angel

> 'CLIENT, STATELESS' and 'SERVER, STATELESS'.

[MIG] Yes, I know what the specs state. Please consider my example as
one where stateful makes sense and where the stateful fsm does not fit
completely (although it is not stateful, because of the reason I
commented, and possibly more).

---

From: Tom Taylor <[email-masked]>
Date: Wed, 30 May 2007 09:00:51 -0400

Having gone through the experience at the ITU-T, I would say that people 
did not understand the rules for creating an application and followed 
the base spec because they thought they had to do so. If there is a 
clear statement in the "How to create a Diameter application" document 
to the effect of what you just said, things will be clearer.

> I think, people should understand that if they define a new Diameter application, and if that Diameter application is not an extension/similar to an existing application (whose state machine they c…
...

---

From: "Tschofenig, Hannes" <[email-masked]>
Date: Wed, 30 May 2007 15:03:20 +0200

Tom, 

Do you think that
http://www.ietf.org/internet-drafts/draft-ietf-dime-app-design-guide-00.
txt
Is going into the right direction? 
What needs to be improved? 

Ciao
Hannes

> > First of all, why does Sh use authorization state machine 
> as defined in RFC3588? There should have been a state machine 
> defined specifically for Sh. They probably thought that the 
> existing authentication state machine is similar to what they need. 
> > 
> > I think, people should understand that if they define a new 
> Diameter application, and if that Diameter application is not 
> an extension/similar to an existing application (whose state 
> machine they can borrow), they need to define a state 
> machine/semantics for it. If there is a need for change, it 
> is the corresponding 3GPP document IMHO.
> > 
> >     Thanks,
> >     Tolga 
> ...
>

---

From: Victor Fajardo <[email-masked]>
Date: Wed, 30 May 2007 09:19:33 -0400

Hi Miguel,

Comments inline:

> messages are related to the same user, so it seems the most logic way 
> to have all them into the same diameter session.
>
> If we try to create diameter client sessions, it implies to have the 
> HSS acting first as diameter server and afterward as diameter client, 
> creating a new session for a message exchange completely related to 
> the previous one. You will have two sessions mixed all along the 
> subscription duration (the subscription ends by sending another SNR 
> that should be in the same session as the first SNR), being both 
> sessions related to same subscription. Not a nice way to do things.
>
> In practice, this subscription dialogues can last for days, even 
> months. From an implementation point of view, you get almost obliged 
> to use a stateless mode. And taking into consideration the other 
> message exchanges that can happen at sh interface (UDR and PUR), they 
> are profile downloads and updates, so it makes sense to do both in 
> stateless mode. As a result, the whole sh becomes stateless, even if 
> subscriptions should be stateful from a pure conceptual point of view.
>
> that allows transaction exchanges whenever applications need them. 
> There are protocols that work in this way. I can see that sh is not 
> the only case (checking ITU-T Liason at 

For me, server sent request make sense only in item (2) of what I have 
described above. This in the case where you already have an established 
stateful sessions and the server sent request are  for subsequent 
message exchanges only. This is probably the only change I'm comfortable 
with. For item(1), it would seem un-natural in a client/server session 
model for the server to send the initial request. In this behavior, the 
client session is expected to be created on receipt of this initial 
request from the server - which for the most part the client is now 
behaving like a server so why not just use it correctly :).

> client-server model. If folks provide good reasons, I will be more 
> than happy to recognize that it is the model that better fits. In any 
> case, I encourage folks to discuss models providing maximum flexibility.

Basic engineering principles teaches us the obvious merits of 
client-server model so it maybe futile to re-iterate that here :). 
Though those principles just may not apply to what 3GPP is doing for 
certain apps. For this discussion, there's two things that I'm not 
comfortable (and maybe my assumptions are wrong):

1. Folks wants to try to change the diameter base protocol to compensate 
for design behaviors that should be fixed/done in the applications 
themselves
2. Folks wants to using the existing authz fsm for purposes it was 
probably not intended to and hence all this issue.

I'm not familiar enough with Sh to authoritatively say otherwise but it 
may have been better that these 3gpp apps (ITU-T as well) define their 
own application fsm instead as Tolga suggested. These SDOs are already 
defining new diameter application so there's nothing hindering this 
approach. If folks are concerned about re-usablility, most of the 
messages and AVPs defined in the base for session maintenance can be 
reused in any new application that is defined provided they follow the 
diameter extension rules.

best regards,
victor

---

From: "Miguel A." Nuñez <[email-masked]>
Date: Wed, 30 May 2007 16:41:40 +0200

Hi Victor,

I try to summarize all we have learnt from this interesting discussion:

1. DIME is not willing to modify their authorization state machines.
They are intended for applications that work using the client-server
model.

2. 3GPP, or others, should define their own session state machines,
following a symmetrical model instead of the client-server one, that
would fit better to the kind of applications they are designing, or have
designed.

3. 3GPP has not done this redesing of the session fsms. Although there
is a draft that recommends how to create applications
(http://www.ietf.org/internet-drafts/draft-ietf-dime-app-design-guide-00.txt), 3gpp specs were done before it existed, so they did not understand how to create them.

Meanwhile, looking from the point of view of someone who wants to
implement 3gpp applications, we keep 'suffering' some contradictions
between the 3gpp specs and rfc 3588.

Maybe we could find an intermediate approach. DIME could design new
state machines, that fit the 3gpp and itu neeeds, instead of modifying
the authz ones. A great number of applications would make use of this
ones, we can consider them of general interest. So, the base protocol
would include authz fsms, accounting fsms and 'symmetrical' fsms. The
session layer is something very related to the base protocol, so related
to DIME group. Does it look reasonable?

Best regards,
Miguel Angel

---

From: Victor Fajardo <[email-masked]>
Date: Wed, 30 May 2007 11:06:58 -0400

Hi Miguel,

> session layer is something very related to the base protocol, so 
> related to DIME group. Does it look reasonable?

We can get more opinion on what others think about this proposal. My 
fear is that others who may want some other type of fsm would want to 
follow the same route; i.e., force 3588bis to fill their needs. In that 
scenario, bis would be bloated and the process may never end. My 
personal preference is that authz and accounting fsms should have been 
in a separate document to begin with but going that direction now for 
these existing fsm's maybe too drastic for other folks and documents who 
got use to having it in 3588. So, at least for me, any new symmetrical 
fsm maybe better defined either in the application specific document or 
other related document if the content is generic enough to be reusable; 
which SDO will write such document may depend on whose going to use the 
fsm more and how generic its going to be.

best regards,
victor

>> > http://www.tschofenig.priv.at/twiki/bin/view/Dime/IetfDimeRoadMap) <http://www.tschofenig.priv.at/twiki/bin/view/Dime/IetfDimeRoadMap%29>
>>
>>

---

From: "Sun, Dong \(Dong\)" <[email-masked]>
Date: Wed, 30 May 2007 14:11:06 -0500

Two cents:
- First, I think it is sensible to make the Diameter more flexible and allow the Diameter server to initiate a Diameter session in support of peer-to-peer applications, as examples, besides the Sh interface, as addressed in http://tools.ietf.org/id/draft-sun-dime-diameter-resource-control-requirements-01.txt, the QoS application may require the peer-to-peer fsm in support of Push model.

- I have no strong view to mandate the Diameter base protocol to define the server initiated session fsm. However, at least, the base protocol should not prohibit this kind of possibility. Otherwise, I don't know how a Diameter application can define a fsm contradicted to base protocol.

- I am not sure if the current 3588 is a pure base protocol and can be used as generic profile for all applications since it does define some fsm for certain applications such as Auth and Acct. It is a bit confused if both 3599 and applications define different fsms using the same command codes. From this perspective, I do not prefer to extend RAR to support server initiated session, the new command code is more reasonable for this kind of FSM, such as PIR defined in aforementioned I-D for QoS application, or PNR for Sh.

Now two options:
- Create new state mechanism and generic command codes in base protocol to support server initiated session
- Create new state mechanism and specific command codes in the applications if needed. Certainly, some clarification is needed in the base protocol to allow this kind of flexibility, which I have not yet seen.

It seems to me the second option is more realistic considering the fact (e.g. 3GPP, ITU and TISPAN have defined (are developing) their own applications). The first option is more elegant from the pure functional perspective.

Cheers,
Dong 

-----Original Message-----
From: Victor Fajardo [mailto:[email-masked]] 
Sent: Wednesday, May 30, 2007 11:07 AM
To: "\"Miguel A.\" Nuñez"
Cc: [email-masked]
Subject: Re: [Dime] Clarification on Auth Server state machine

Hi Miguel,

> related to DIME group. Does it look reasonable?

We can get more opinion on what others think about this proposal. My fear is that others who may want some other type of fsm would want to follow the same route; i.e., force 3588bis to fill their needs. In that scenario, bis would be bloated and the process may never end. My personal preference is that authz and accounting fsms should have been in a separate document to begin with but going that direction now for these existing fsm's maybe too drastic for other folks and documents who got use to having it in 3588. So, at least for me, any new symmetrical fsm maybe better defined either in the application specific document or other related document if the content is generic enough to be reusable; which SDO will write such document may depend on whose going to use the fsm more and how generic its going to be.

best regards,
victor

>> >> 1. where the first app specific exchange is initiated by the 
>> >> server - I still have doubts about this since this maybe solved by 
>> >> other means such as having the "application server" create 
>> >> diameter client sessions to initiate a conversation.
>> >> 2. where subsequent app specific exchanges are initiated by the 
>> >> server - this maybe acceptable in stateful sessions where 
>> >> applications may need similar msg exchange behavior like RAR. 
>> >> However, for stateless sessions, this not applicable and solutions becomes similar to (1).
>> >>     
>> > messages are related to the same user, so it seems the most logic 
>> > way to have all them into the same diameter session.
>> >
>> > If we try to create diameter client sessions, it implies to have 
>> > the HSS acting first as diameter server and afterward as diameter 
>> > client, creating a new session for a message exchange completely 
>> > related to the previous one. You will have two sessions mixed all 
>> > along the subscription duration (the subscription ends by sending 
>> > another SNR that should be in the same session as the first SNR), 
>> > being both sessions related to same subscription. Not a nice way to do things.
>> >
>> > months. From an implementation point of view, you get almost 
>> > obliged to use a stateless mode. And taking into consideration the 
>> > other message exchanges that can happen at sh interface (UDR and 
>> > PUR), they are profile downloads and updates, so it makes sense to 
>> > do both in stateless mode. As a result, the whole sh becomes 
>> > stateless, even if subscriptions should be stateful from a pure conceptual point of view.
>> >
>> > applications, and allow servers to send requests at least in 
>> > stateful mode. It would be even greater to have a completely 
>> > flexible protocol that allows transaction exchanges whenever applications need them.
>> > <http://www.tschofenig.priv.at/twiki/bin/view/Dime/IetfDimeRoadMap%29>
>>
>>
>> For me, server sent request make sense only in item (2) of what I 
>> have described above. This in the case where you already have an 
>> established stateful sessions and the server sent request are  for 
>> subsequent message exchanges only. This is probably the only change 
>> I'm comfortable with. For item(1), it would seem un-natural in a 
>> client/server session model for the server to send the initial 
>> request. In this behavior, the client session is expected to be 
>> created on receipt of this initial request from the server - which 
>> for the most part the client is now behaving like a server so why not just use it correctly :).
>>
>>
>> >
>> > session layer with the limitations of a client-server model, when 
>> > having available a great tranport layer without them.
>> >
>> > than happy to recognize that it is the model that better fits. In 
>> > any case, I encourage folks to discuss models providing maximum flexibility.
>>
>> 1. Folks wants to try to change the diameter base protocol to 
>> compensate for design behaviors that should be fixed/done in the 
>> applications themselves 2. Folks wants to using the existing authz 
>> fsm for purposes it was probably not intended to and hence all this 
>> issue.
>>
>> I'm not familiar enough with Sh to authoritatively say otherwise but 
>> it may have been better that these 3gpp apps (ITU-T as well) define 
>> their own application fsm instead as Tolga suggested. These SDOs are 
>> already defining new diameter application so there's nothing 
>> hindering this approach. If folks are concerned about re-usablility, 
>> most of the messages and AVPs defined in the base for session 
>> maintenance can be reused in any new application that is defined 
>> provided they follow the diameter extension rules.
>>
>>
>> best regards,
>> victor
>>
>> >
>> >
>> >> I hope more folks can add their input to this so we can move 
>> >> forward more quickly on this issue.
>> >>
>> >> best regards,
>> >> victor
>> >>
>> >>
>> >>     
>>
>>
>>

---

From: Tom Taylor <[email-masked]>
Date: Wed, 30 May 2007 15:50:58 -0400

I would be in favour of taking the specific authz application and FSM 
out of Base into a separate document and making Base a more general 
document. If labour is needed for that, I could help.

If that doesn't appeal because the IESG wants to keep control of the 
protocol (a historical position), then I would favour putting 
peer-to-peer at the application level into a separate document rather 
than the base draft, and modifying base to allow such operation.

---

From: "Asveren, Tolga" <[email-masked]>
Date: Wed, 30 May 2007 16:20:40 -0400

inline...

> From: Tom Taylor [mailto:[email-masked]]
> Sent: Wednesday, May 30, 2007 3:51 PM
> To: Sun, Dong (Dong)
> Cc: [email-masked]; =?ISO-8859-1?Q?=22=5C=22M?=@sonussf2.sonusnet.com
[TOLGA]IMHO, that is technically the best option.
> than the base draft, and modifying base to allow such operation.
[TOLGA]I agree. Let's keep the base as clean as possible.
> 
> Sun, Dong (Dong) wrote:
> > Two cents:
> > - First, I think it is sensible to make the Diameter more flexible and
> allow the Diameter server to initiate a Diameter session in support of
> peer-to-peer applications, as examples, besides the Sh interface, as
> addressed in http://tools.ietf.org/id/draft-sun-dime-diameter-resource-
> control-requirements-01.txt, the QoS application may require the peer-to-
> peer fsm in support of Push model.
> >
> > - I have no strong view to mandate the Diameter base protocol to define
> the server initiated session fsm. However, at least, the base protocol
> should not prohibit this kind of possibility. Otherwise, I don't know how
> a Diameter application can define a fsm contradicted to base protocol.
> >
> > - I am not sure if the current 3588 is a pure base protocol and can be
> used as generic profile for all applications since it does define some fsm
> for certain applications such as Auth and Acct. It is a bit confused if
> both 3599 and applications define different fsms using the same command
> codes. From this perspective, I do not prefer to extend RAR to support
> server initiated session, the new command code is more reasonable for this
> kind of FSM, such as PIR defined in aforementioned I-D for QoS
> application, or PNR for Sh.
> >
> > Now two options:
> > - Create new state mechanism and specific command codes in the
> applications if needed. Certainly, some clarification is needed in the
> base protocol to allow this kind of flexibility, which I have not yet
> seen.
> >
> > It seems to me the second option is more realistic considering the fact
> (e.g. 3GPP, ITU and TISPAN have defined (are developing) their own
> applications). The first option is more elegant from the pure functional
> perspective.
> >
> > Cheers,
> > Dong
> >
> scenario, bis would be bloated and the process may never end. My personal
> preference is that authz and accounting fsms should have been in a
> separate document to begin with but going that direction now for these
> existing fsm's maybe too drastic for other folks and documents who got use
> to having it in 3588. So, at least for me, any new symmetrical fsm maybe
> better defined either in the application specific document or other
> related document if the content is generic enough to be reusable; which
> SDO will write such document may depend on whose going to use the fsm more
> and how generic its going to be.
> >
> > best regards,
> > victor
> >
> >>
> >> Best regards,
> >> Miguel Angel
> >>
> >>
> >>
> >>

---

From: Victor Fajardo <[email-masked]>
Date: Wed, 30 May 2007 16:37:30 -0400

Hi Sun,

> - I have no strong view to mandate the Diameter base protocol to define the server initiated session fsm. However, at least, the base protocol should not prohibit this kind of possibility. Otherwis…

In my understanding, and folks can correct me if this is not accurate, 
an application is certainly free to define its own fsm and I don't think 
the current base protocol spec bans such approach. Consider the example 
given by Marco on rfc4006.

> - I am not sure if the current 3588 is a pure base protocol and can be used as generic profile for all applications since it does define some fsm for certain applications such as Auth and Acct. It…

This maybe the best approach for your application. For others who may 
wish to re-use existing commands (for their own fsm or for whatever 
reasons) its probably best if you check out the extensibility guidelines 
in 
http://www.ietf.org/internet-drafts/draft-ietf-dime-app-design-guide-00.txt. 

> - Create new state mechanism and specific command codes in the applications if needed. Certainly, some clarification is needed in the base protocol to allow this kind of flexibility, which I have n…

I would prefer the second approach though I'm not sure what type of 
clarification is required since the base protocol currently does not 
restrict an application in defining its own fsm. If folks have a 
differing view on when and how to use the session fsm defined in the 
base then maybe that can go to the app design guide docs instead. As for 
the first option, it maybe is less elegant as I mentioned before since 
it forces the base protocol to solve a problem of the application 
(probably making the base protocol even more confusing).

regards,
victor

---

From: Victor Fajardo <[email-masked]>
Date: Wed, 30 May 2007 16:42:47 -0400

Hi Tom,
> than the base draft, and modifying base to allow such operation.

Agree with the latter option as well.

regards,
victor