Subject: RE: [AAA-WG]: Diameter SIP app: next steps

From: <[email-masked]>
Date: Thu, 7 Apr 2005 09:53:44 +0300

Miguel,

> As you probably know, the Diameter SIP application supports this 
> operational mode where nonces are generated in the Diameter server. it 
> could be possible to have another mode of operation where nonces are 
> generated in the Diameter client (SIP server). Actually, this is the 
> approach that has been taken by the RADIUS HTTP/SIP Digest draft: there 
> are two modes of operation, one where nonces are generated in the RADIUS 
> server; the other where nonces are generated in the RADIUS client.
> 
> Since Diameter SIP app does not provide one of this modes, it won't be 
> possible to provide a smooth transition or compatibility between RADIUS 
> and Diameter. We have been asked to enhance the Diameter SIP application 
> by adding the mode of operation where nonces are generated in the 
> Diameter client (SIP server).
> 
> I have been doing an investigation and there is no technical concern why 
> this wouldn't work. The current Diameter SIP app draft does not 
> implement this mode because we never had requirements. But now we have 
> them, and we should do it.
> 
> So I would be creating a new revision of the draft in the next weeks. If 
> someone has any comment, please do it now.

What is the real requirement for this?  It seems that the RADIUS HTTP/SIP
digest draft has an additional mode of operation that is not included 
the Diameter SIP app.  What is the usage / deployment scenario where this
is needed? If there isn't a pressing need for this, I think we should not
support this mode in the current Diameter SIP application, but leave it
to an extension if there is need or desire.  

At some point, we've got to finish this work, and not endlessly tweak this
stuff forever.  Unless there is concensus on adding this feature, I don't think
we address it.

John

---

From: Miguel Garcia <[email-masked]>
Date: Thu, 07 Apr 2005 10:32:32 +0300

John:

I agree with your statement. It seems to be a bit hard to understand 
that because a different protocol with different requirements came at a 
later stage, now we need to provide a full backwards compatibility with 
such protocol.

I have also the same concerns regarding the timescales. We have been 
drafting the Diameter SIP app for a few years, and never, never, ever 
got requirements to support nonces generated in the client, otherwise, 
we would have implementted in the draft.

At some point in time we have to decide to close the requirements and 
finish this work. I may also remind that, when progressing RFCs in the 
three stages of standards track, those things that are not implemented 
are moved out of the draft. So I have the suspicion that this nonces 
generated in the client will never be implemented, because we never got 
a requirement about this. Therefore, I think it is a waste of time to 
document it.

I also agree that what we could do, at this stage, is to make sure that 
this mode of operation can be added at later stage, if someone requires 
it. This exersice would not take that much time now. But adding this 
mode of operation will delay this work for 6-9 months.

So would people have a problem if we inspect the Diameter SIP app to 
allow easy extensibility of client-generated nonces, but we don't add 
this mode of operation at this time? Is this a reasonable proposal?

/Miguel

-- 
Miguel A. Garcia           tel:+358-50-4804586
sip:[email-masked]
Nokia Research Center      Helsinki, Finland