[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Diameter Considerations Section (VLAN/Priority, Delegated Prefix, etc.)
FWIW - This proposal would answer my concerns expressed in the COMMENTs
made vs. the two documents on the IESG agenda this week.
Dan
> -----Original Message-----
> From: owner-radiusext@ops.ietf.org
> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba
> Sent: Wednesday, June 07, 2006 7:19 PM
> To: radiusext@ops.ietf.org
> Cc: rdroms@cisco.com
> Subject: Diameter Considerations Section (VLAN/Priority,
> Delegated Prefix, etc.)
>
> Jari Arkko has suggested a new template for Diameter
> Considerations sections in RADEXT WG documents. I believe
> this suggestion applies to both the VLAN/Priority and
> Delegated Prefix attributes.
>
> --------------------------------------------------------------
> ------------------
> From: Jari Arkko [mailto:jari.arkko@piuha.net]
> Sent: Wed 6/7/2006 3:29 AM
> To: iesg@ietf.org
> Cc: radext-chairs@tools.ietf.org
> Subject: DISCUSS: draft-ietf-radext-vlan
>
>
> Discuss:
> I am raising an issue that is largely about the same text as
> Dan already commented on. But the main issue is not
> inconsistency in this specification but rather the need to
> fulfill requirements from the WG's charter and the desire to
> keep the RADIUS and Diameter protocols interoperable through gateways.
>
> Fortunately, I think we can correct this issue relatively easily.
>
> The document said this:
>
> >4. Diameter Considerations
> >
> > Diameter needs to define identical attributes with the same Type
> > values. The attributes should be available as part of the NASREQ
> > application [RFC4005], as well as the Diameter EAP application
> > [RFC4072].
>
> But RADEXT charter says:
>
> >All RADIUS work MUST be compatible with equivalent facilities in
> >Diameter. Where possible, new attributes should be defined
> so that the
> >same attribute can be used in both RADIUS and Diameter without
> >translation.
>
> In this case I believe there is no technical reason to
> require different attributes. I would suggest the following
> contents for Section 4:
>
> When used in Diameter, the attributes defined in this
> specification can be used as Diameter AVPs from the
> Code space 1-255, i.e., RADIUS attribute compatibility
> space. No additional Diameter Code values are therefore
> allocated. The data types of the attributes are as
> follows:
>
> Egress-VLANID OctetString
> Ingress-Filters Enumerated
> Egress-VLAN-Name UTF8String
> User-Priority-Table OctetString
>
> The attributes in this specification have no special
> translation requirements for Diameter to RADIUS or
> RADIUS to Diameter gateways, i.e., the attributes
> are copied as is, except for changes relating to
> headers, alignment, and padding. See also
> [RFC 3588] Section 4.1 and [RFC 4005] Section 9.
>
> What this specification says about the applicability
> of the attributes for RADIUS Access-Request applies
> in Diameter to AA-Request [RFC 4005] or Diameter-EAP-Request
> [RFC 4072]. What is said about Access-Challenge applies
> in Diameter to AA-Answer [RFC 4005] or Diameter-EAP-Answer
> [RFC 4072] with Result-Code AVP set to
> DIAMETER_MULTI_ROUND_AUTH.
>
> What is said about Access-Accept applies in Diameter
> to AA-Answer or Diameter-EAP-Answer that indicates
> success. Similarly, what is said about Access-Reject
> applies in Diameter to AA-Answer or Diameter-EAP-Answer
> that indicates failure.
>
> What is said about COA-Request applies in Diameter
> to Re-Auth-Request [RFC 4005].
>
> What is said about Accounting-Request applies to
> Diameter Accounting-Request [RFC 4005] as well.
>
>
>
> --
> 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/>