RADIUS Dynamic Authorization Client MIB
RFC 4672

Notify list changed from dnelson@enterasys.com, aboba@internaut.com, bernard_aboba@hotmail.com, stefaan.de_cnodder@alcatel.be, njonnala@cisco.com, mchiba@cisco.com,david.kessens@nokia.com', dromasca@avaya.com to david.kessens@nokia.com', bernard_aboba@hotmail.com, aboba@internaut.com, dnelson@enterasys.com

State Change Notice email list have been change to dnelson@enterasys.com, aboba@internaut.com, bernard_aboba@hotmail.com, stefaan.de_cnodder@alcatel.be, njonnala@cisco.com, mchiba@cisco.com;david.kessens@nokia.com'; dromasca@avaya.com from dnelson@enterasys.com, aboba@internaut.com, bernard_aboba@hotmail.com, stefaan.de_cnodder@alcatel.be, njonnala@cisco.com, mchiba@cisco.com;david.kessens@nokia.com

review of a pre-release of the new revisions (rev 4):
Can be fixed before submitting to ID-repository.

-----Original Message-----
From: owner-radiusext@ops.ietf.org
[mailto:owner-radiusext@ops.ietf.org]On Behalf Of Wijnen, Bert (Bert)
Sent: Saturday, March 18, 2006 23:44
To: stefaan.de_cnodder@alcatel.be
Cc: radiusext@ops.ietf.org; Dan Romascanu (E-mail)
Subject: RE: radius dynauth client/server mibs structure


I checked both new documents.

You may want to check on page 7/8:
              Copyright (C) The Internet Society (2006).  Initial
              version as published in RFC yyyy;
              for full legal notices see the RFC its"
  -- RFC Ed.: replace yyyy with actual RFC number & remove this note

So I huess this sentence is incomplete: see the RFC its ???
Probably should be: see the RFC itself.


More below.

I propose to make the changes as suggested here and then submit to ID-repository.
I believe it opens up again on Monday during IETF65.


See further inline:


> -----Original Message-----
> From: stefaan.de_cnodder@alcatel.be
> [mailto:stefaan.de_cnodder@alcatel.be]
> Sent: Monday, March 13, 2006 22:05
> To: Nelson, David; Wijnen, Bert (Bert)
> Cc: Nagi Reddy Jonnala (njonnala); j.schoenwaelder@iu-bremen.de;
> radiusext@ops.ietf.org
> Subject: Re: radius dynauth client/server mibs structure
>
>
>
> Hi Bert, Dave,
>
> The updated versions are attached.
>
> Changes are:
> - change 2005 into 2006 in DESCRIPTION of MIB

good, but see above

> - group the scalars according the comment of Juergen

Looks good to me now


> - add sentence "This counter wraps from the maximum value to
> zero and is
> reset upon system (re)initialization." for all counters of type
> Counter32

Mmm... the "wraps from the max value to zero" is redundant, because
that is the behaviour of every Counter32 and Counter64. That is
already specified in RFC2578.
W.r.t "is reset upon system (re)initialization", that is not exactly
waht we wanted either. I do not know what you mean with "reset".
It is not REQUIRED that counter reset to sero (if that is what you mean).
They MAY do so, butnot required.
I think what you want to write is:

  This counter will only experience a discuntinuity when the system
  (re)starts as indicated by the value of sysUpTime.


> - remove ref to IANA copyright.

thanks

> - some minor formatting (line breaks in the mib)
>

OK

My comments to the other 4 mib docs (2618bis etc) also apply for
your use of InetAddress and InetAddressType. I know I did say (in my point 3)
last time that this was acceptable for Informational RFC. But now that I
reviewed the other MIB modules and now that I am asking for the below
updates tyo those, it would be best to do so too for these 2
modules, in order to be consistent for all RADIUS related MIB modules.
So pls translate the following to your own objects and consider to
make similar changes:

-  radiusAuthServerInetAddress OBJECT-TYPE
        SYNTAX    InetAddress
        MAX-ACCESS read-only
        STATUS    current
        DESCRIPTION
              "The IP address of the RADIUS authentication
                server referred to in this table entry, using
                the version neutral IP address format."
        ::= { radiusAuthServerExtEntry 3 }

  according to RFC4001, you MUST specify which object of SYNTAX
  InetAddressType controls the format of this object. I t is clear
  which one  it is, b ut it would be good to add that.

- radiusAuthClientServerInetPortNumber
  According to RFC4001, you must specify what the value zero means
  for this object.

- for this one
  radiusAuthClientExtMIBCompliance MODULE-COMPLIANCE
        STATUS  current
        DESCRIPTION
              "The compliance statement for authentication
              clients implementing the RADIUS Authentication
              Client IPv6 Extensions MIB.  Implementation of
              this module is for entities that support IPv6,
              or support IPv4 and IPv6."
        MODULE  -- this module
              MANDATORY-GROUPS { radiusAuthClientExtMIBGroup }

        ::= { radiusAuthClientMIBCompliances 2 }

  I think it would be better to do:

  radiusAuthClientExtMIBCompliance MODULE-COMPLIANCE
        STATUS  current
        DESCRIPTION
              "The compliance statement for authentication
              clients implementing the RADIUS Authentication
              Client IPv6 Extensions MIB.  Implementation of
              this module is for entities that support IPv6,
              or support IPv4 and IPv6."
        MODULE  -- this module
              MANDATORY-GROUPS { radiusAuthClientExtMIBGroup }

        OBJECT    radiusAuthServerInetAddressType
        SYNTAX    InetAddressType { ipv4(1), ipv6(2) }
        DESCRIPTION
          "An implementation is only required to support IPv4 and
            globally unique IPv6 addresses."

        OBJECT    radiusAuthServerInetAddress
        SYNTAX    InetAddress (SIZE(4|16))
        DESCRIPTION
          "An implementation is only required to support IPv4 and
            globally unique IPv6 addresses."

Bert
> I tried a diff but that output is rather messy, so I sent you the
> complete drafts.
>
> Thanks,
> Stefaan
>

AD review:

-----Original Message-----
From: Wijnen, Bert (Bert)
Sent: Friday, March 03, 2006 16:14
To: radiusext@ops.ietf.org
Subject: AD review: radius dynauth client/server mib documents



1. In the MIB MODULE IDENTITY DESCRIPTION clause it says:

          DESCRIPTION
              "The MIB module for entities implementing the server
              side of the Dynamic Authorization Extensions to Remote
              Authentication Dial In User Service (RADIUS) protocol.

              Copyright (C) The Internet Society (2005).  Initial
              version as published in RFC yyyy;
              for full legal notices see the RFC itself.  Supplementary
              information may be available on
              http://www.ietf.org/copyrights/ianamib.html."

  That last sentence is NOT applicable. There is nothing in this MIB
  module that is mainatined by IANA, so their copy-right web page is
  not relevant. Fix is to just remove last sentence.

2. The a whole serioes of Counter32 objects.
  I wonder what the object is to indicate a counter-discontinuity?
  Or can such only happen at system restart/reboot?
  See RFC2578 that explains this in sect 7.1.6
  RFC4181, sect 4.6.1.2 (1st bullet) also speaks to it.

3. I see
  radiusDynAuthClientAddressType OBJECT-TYPE
          SYNTAX    InetAddressType
          MAX-ACCESS read-only
          STATUS    current
          DESCRIPTION
                "The type of IP address of the RADIUS Dynamic
                Authorization Client referred to in this table entry."
          ::= { radiusDynAuthClientEntry 2 }

  radiusDynAuthClientAddress OBJECT-TYPE
          SYNTAX    InetAddress
          MAX-ACCESS read-only
          STATUS    current
          DESCRIPTION
                "The IP address value of the RADIUS Dynamic
                Authorization Client referred to in this table entry,
                using the version neutral IP address format."
          ::= { radiusDynAuthClientEntry 3 }


  So, the radiusDynAuthClientAddress needs to specify that the address is
  formatted according to the value of radiusDynAuthClientAddressType.
  Also, as far as I can tell, any addressType could be present here,
  so formally, you would need to describe when a dns name has been
  resolved (if it occurs).

Same for both MIB documents.

Point 1 I can do with an RFC-Editor note.
Point 2 I can also address with an RFC-Editor not if the intend (default)
        is that a dsiscuntinuity can only occur at system re-initiatlization.
        If so, I suggest to add an entry to the DESCRIPTION clause of the
        table itself that states:

            Discontinuities for all counter32 objects in this table can
            only occur at system re-initialization.
            So no specific discontinuity onjects have been defined.
Point 3 Mmm... I guess there will only be ipv4 or ipv6 addresses.
        If so, I can live with it since this is a read-only MIB module
        and the doc is Informational.

Bert
> -----Original Message-----
> From: Wijnen, Bert (Bert)
> Sent: Friday, March 03, 2006 15:36
> To: 'Nagi Reddy Jonnala (njonnala)'; j.schoenwaelder@iu-bremen.de;
> radiusext@ops.ietf.org
> Subject: RE: radius dynauth client/server mibs structure
>
>
> Are there implementations already?
> If not, I would also recommend to make the change suggested
> by Juergen.
> If yes, even then the suggested change is still simple now.
>
> The disadvantage of not doing so is in the future when adding scalars
> and thing not having grouped as nicely and so more complexity.
>
> This is not a blocking comment, just another MIB-type person believing
> that the change would be real EASY now, and it will certainly make
> things cleaner/easier in the future.
>
> Bert

PROTO write-up by WG chairs:

This PROTO IESG submission write-up covers the following Internet Drafts, from the RADEXT WG, that should be considered for a "group ballot":

draft-ietf-radext-dynauth-client-mib-03.txt
draft-ietf-radext-dynauth-server-mib-03.txt

1) Have the chairs personally reviewed this version of the ID and do
  they believe this ID is sufficiently baked to forward to the IESG
  for publication?

Yes.

2) Has the document had adequate review from both key WG members and
  key non-WG members? Do you have any concerns about the depth or
  breadth of the reviews that have been performed?

The documents have at various stages received comment from WG members Glen Zorn, Alan DeKok, Greg Weber, Bert Wijnen and Jari Arkko as well as MIB Doctor Dan Romascanu.

3) Do you have concerns that the document needs more review from a
  particular (broader) perspective (e.g., security, operational
  complexity, someone familiar with AAA, etc.)?

No.

4) Do you have any specific concerns/issues with this document that
  you believe the ADs and/or IESG should be aware of? For example,
  perhaps you are uncomfortable with certain parts of the document,
  or whether there really is a need for it, etc., but at the same
  time these issues have been discussed in the WG and the WG has
  indicated it wishes to advance the document anyway.

No.  There was an extensive WG discussion as to whether the use of terminology in the MIB documents effectively created normative extensions to the underlying protocol RFC.  This issue was satisfactorily resolved.

5) How solid is the WG consensus behind this document?  Does it
  represent the strong concurrence of a few individuals, with others
  being silent, or does the WG as a whole understand and agree with
  it?

These documents have generated about the same level of comments as others completing WGLC in the RADEXT WG.

6) Has anyone threatened an appeal or otherwise indicated extreme
  discontent?  If so, please summarize what are they upset about.

No.

7) Have the chairs verified that the document adheres to _all_ of the
  ID nits?  (see http://www.ietf.org/ID-nits.html).

Yes.

8) Does the document a) split references into normative/informative,
  and b) are there normative references to IDs, where the IDs are not
  also ready for advancement or are otherwise in an unclear state?
  (Note: the RFC editor will not publish an RFC with normative
  references to IDs, it will delay publication until all such IDs are
  also ready for publication as RFCs.)

(a) Yes.  (b) No.

9) For Standards Track and BCP documents, the IESG approval
  announcement includes a write-up section with the following
  sections:

The two MIB documents are Informational, as the base RFC [RFC3576] is Informational.

State Change Notice email list have been change to dnelson@enterasys.com, aboba@internaut.com, bernard_aboba@hotmail.com, stefaan.de_cnodder@alcatel.be, njonnala@cisco.com, mchiba@cisco.com;david.kessens@nokia.com from dnelson@enterasys.com, aboba@internaut.com, bernard_aboba@hotmail.com