RE: : Re: authors 48 hours: RFC 4005

David,

> >  we could use one of the unused flags in the
> >Diameter packet header and set it when a Diameter message passes
> >through a RADIUS->Diameter gateway; this would require special
> >purpose logic in the Diameter "server", however it would ensure that
> >the RADIUS rules were followed (if possible).
> 
> Well, I'm not convinced that the server MUST know the origin of the request.
> Operationally that would depends on whether the response would violate RADIUS rules.
> I'm not sure what service the server would return to a NAS that wouldn't work, but there is
> a possibility, so lets say there's something we want here.
> 
> Some RADIUS systems solve this (in particular for VSAs) by having the 
> network admin configure a NAS model table along with the IP address.  They 
> could add a RADIUS/Diameter protocol type.  But that's out of protocol.
> 
> But I've actually always liked identifying information in 
> requests.  Instead of a flag, I would think an Origin-Host-Protocol AVP 
> would be useful.  (personally, I'd love to see Make, Model, and version 
> number too)  With a protocol enumeration, heck someone could build a TACACS 
> to Diameter gateway.
> 
> I think this is a good idea.  It should probably be re-fitted into the 
> Base, and included in all Diameter requests.  Likewise, a RADIUS equivalent attribute 
> could be created.

I think that this might be a good way to solve this, going forward. Could we document
this behavior in a new draft; this could potentially update Diameter Base, if
the wg agrees.

John