Re: : Diameter SIP app: next steps

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


Loughney John (Nokia-NRC/Helsinki) wrote:

> 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

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