FW: MIB Doctor Last Call on 2 RADEXT MIB documents

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

On Wed, Feb 08, 2006 at 03:22:54AM +0100, Wijnen, Bert (Bert) wrote:
> These 2 documents:
> 
>   draft-ietf-radext-dynauth-client-mib-03.txt
>   draft-ietf-radext-dynauth-server-mib-03.txt
> 
> are on my plate for publication as Informational documents.
> I do not plan to do IETF Last Call (since they are
> informational). I'd like to do a 2 week MIB Doctor Last Call
> instead, so that any of you who is interested can check if 
> they have any serious issues.

Juergen did comemnt. Thanks!

I did go through them myself today.
I posted the following AD review comments with proposals
for quick resolution (on a Proposed Standard I might have
been a bit more strict). Let me know if anyone has an issue
with that.

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