[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Diameter Considerations Section (VLAN/Priority, Delegated Prefix, etc.)



A question inline at GDW> 

> -----Original Message-----
> From: owner-radiusext@ops.ietf.org 
> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba
> Sent: Wednesday, June 07, 2006 12:19 PM
> To: radiusext@ops.ietf.org
> Cc: Ralph Droms (rdroms)
> 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.

GDW> In section 4.1 of RFC 3588, I see:
      Unless otherwise noted, AVPs will have the following default AVP
      Flags field settings:

         The 'M' bit MUST be set.  The 'V' bit MUST NOT be set.

Is the M-bit supposed to be set for these RADIUS attrs?

Greg

> 
>    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/>