This makes sense to me.
--Jari
Miguel Garcia wrote:
Hi:
I did some investigation of what is the reason why Diameter app does not support client generated nonces, and I found out that there is no technical reason why this mode of operation is not supported. We simply never had any requirements to support this scenario.
You might remember that the Diameter SIP app. was originated in 3GPP, where nonces are generated in the Diameter server. Additionally, the Diameter SIP app. was born earlier than the RADIUS Digest draft. So no requirements led to no support.
Now, we can add this later requirement and provide a solution for it. Is it the decision that, in order to clear the Diameter SIP app in the IESG we need to add this mode of operation? At this stage I wouldn't like to add anything that is essential for the publication of the document as an RFC.
/Miguel
Bernard Aboba wrote:
I am more worried about Wolfgang's concerns about "Diameter SIP document
is likely to be blocked based on the lack of compatibility with RADIUS
Digest". Can someone expand these concerns, because we should addressed
them. I thought that we have limited compatibility just restricted by
the smaller scope of the RADIUS draft.
It is ok for Diameter SIP to be a *superset* of the RADIUS Digest
document. It is not ok for Diameter SIP to be unable to translate AVPs or
modes of operation that occur within RADIUS Digest.
From reading the RADIUS Digest Diameter compatibility section, it would
appear that Diameter SIP cannot handle a situation where the RADIUS client
generates nonces. If so, this would mean that Diameter SIP is a *subset*
of RADIUS Digest functionality.
-- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/radiusext/>
-- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/radiusext/>