What happens in the instance that a diameter->radius gateway can't translate a packet? There must be some exception path, right? If so, why couldn't we leave in the MUST NOT for mixture of filter-id and nas-filter-rule attributes and have the gateway generate an error to avoid wedging both attributes into a radius packet? It just feels wrong to have to carry forward diameter sloppiness. MS > -----Original Message----- > From: owner-radiusext@ops.ietf.org > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Nelson, David > Sent: Monday, November 27, 2006 11:59 AM > To: radiusext@ops.ietf.org > Subject: RE: Inclusion of Filter-Id and NAS-Filter-Rule AVPs > > Bernard Aboba writes... > > > Perhaps the best solution is simply to say this in the document. > > That may, in fact, be the best we can do. > > > For example: > > > > "The NAS-Filter-Rule attribute is not intended to be used > concurrently > > with any other filter rule attribute, including Filter-Id (11) and > > NAS-Traffic-Rule [Traffic] attributes. > > NAS-Filter-Rule and NAS-Traffic-Rule attributes MUST NOT > appear in the > > same RADIUS packet. If a NAS-Traffic-Rule attribute is > present, a NAS > > implementing this specification MUST silently discard > NAS-Filter-Rule > > attributes, if present. Filter-Id and NAS-Filter-Rule attributes > > SHOULD NOT appear in the same RADIUS packet. > > > > Given the absence in [RFC4005] of well-defined precedence rules for > > combining Filter-Id and NAS-Filter-Rule attributes into a > single rule > > set, the behavior of NASes receiving both attributes is > undefined, and > > therefore a RADIUS server implementation cannot assume a consistent > > behavior." > > This seems OK to me. > > > > -- > 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/> >
Attachment:
smime.p7s
Description: S/MIME cryptographic signature