Re: [Dime] Review of draft-ietf-dime-rfc3588bis-17

[Victor Fajardo <vfajardo at tari.toshiba.com>]

Hi Qin,

Thanks. Comments inline:

> Hi, Vicotor:
> Thank for your feedback. I have a few more followup comments below, Please see inline.
>
> Regards!
> -Qin
> ----- Original Message ----- 
> From: "Victor Fajardo" <vfajardo at tari.toshiba.com>
> To: "Qin Wu" <sunseawq at huawei.com>
> Cc: <dime at ietf.org>
> Sent: Thursday, June 18, 2009 9:21 PM
> Subject: Re: [Dime] Review of draft-ietf-dime-rfc3588bis-17
>
>
>   
> > Hi Qin,
> >
> > Thanks for the review.
> >     
> > > [snip]
> > > "
> > > 1.  Introduction
> > > .............
> > > Server-initiated messages
> > >
> > > While RADIUS server-initiated messages are defined in [RFC5176],
> > > support is optional.  This makes it difficult to implement
> > > features such as unsolicited disconnect or reauthentication/
> > > reauthorization 
> > > "
> > >  [Qin] Reauthentication/reauthoriation is not necessary to be server-initiated?
> > >   
> > >       
> >     
> > >   e.g., In RFC5296"EAP Extensions for EAP Re-authentication Protocol (ERP)
> > >    ", EAP Re-authentication is host/peer initiated, isn't it?
> > >    So it is not very accurate to say the reauthentcation is server-initiated .
> > >
> > > "
> > >   
> > >       
> > mmm ... the statement above is just giving an example of 
> > server-initiated messages. i don't think it stating that re-authz are 
> > server-initiated only.
> >     
> [Qin]:  As described in draft-ietf-dime-rfc3588bis-17,
> "
> This makes it difficult to implement features such as unsolicited disconnect or reauthentication/ reauthorization 
> "
> It seems reauthentication/reauthorization is a generic feature used here which, I am afraid, does not include EAP re-authentification case
> described in RFC5296. In this sense, I would like to suggest reword as:
> "
> This makes it difficult to implement features such as unsolicited disconnect or reauthentication/ reauthorization for Credit control.
> "
>   


I'm not sure I fully understand. Do you mean you don't want a generic 
statement because it would not include EAP ? I was thinking the 
opposite. A generic statement would encompass a broader scope right ?


> [snip]
>
>   
> > > "
> > > 8.3.  Server-Initiated Re-Auth
> > >
> > >    A Diameter server may initiate a re-authentication and/or re-
> > >    authorization service for a particular session by issuing a Re-Auth-
> > >    Request (RAR).
> > > "
> > > [Qin] Can you provide some reference as regarding this mechanism?
> > >   
> > >       
> > I'm guessing diameter credit-control has server-initiated RAR ...
> >     
>
> [Qin]
> Does it seem confusion to use the terminology "Re-Auth" in Credit Control  which conflicts with
> the terminology "Re authentication" used in the RFC5296 or Diameter Re-authentication WG draft?
> i.e, Does Re-auth in Credit control has the same meaning as the Re-auth in the EAP reauthentication described in the RFC5296?
>   

I'm not too sure about the history for Diameter CC nor the reasoning for 
its terminology. I guess the more pertinent question is how this relates 
to bis. At least for bis the term "Re-Auth" can indicate authorization 
and/or authentication.

>   
> > > "
> > >    For example, for pre-paid services, the Diameter server that
> > >    originally authorized a session may need some confirmation that the
> > >    user is still using the services.
> > > "
> > > [Qin] If the security information(e.g., keys) is expired, do we need to depend on
> > >  Server-Initiated Re-auth to renew the security information? In this case, it seems
> > >  that the Client also can initiate this Re-auth?
> > >   
> > >       
> > Yes the client can perform re-auth in this scenario. The base protocol 
> > does not limit what the diameter applications can do. it simply provides 
> > a framework for it.
> >     
>
> [Qin] As you mentioned above, the credit-control has server-initiated RAR, it seems the 
> server-initiated RAR has different meaning from what I examplified above, hasn't it?
>   

Ok. Then I'm not really sure what your comparing re-auth againts. Are 
you comparing client vs. server re-auth ? In that case, is there 
anything broken in the bis that relates to this ?

regards,
victor