RADEXT Issue 194

["Nelson, David" <dnelson@enterasys.com>]

Issue 194 (reproduced below) has been addressed in the -03 MIB documents.  Bert's comment came in on a strawman -03, and I made the suggested revisions prior to submitting the -03 documents to the Secretariat.

------------------------------------------------------------------

Issue 194: InetPortNumber
Submitter name: Bert Wijnen
Submitter email address: bwijnen@lucent.com
Date first submitted: May 11, 2006
Reference: http://ops.ietf.org/lists/radiusext/2006/msg00504.html
Document: Auth-Client-MIB-03, Acct-Client-MIB-03
Comment type: Editorial
Priority: 1
Section: 7
Rationale/Explanation of issue:
When I read:
   radiusAuthClientServerInetPortNumber  OBJECT-TYPE
         SYNTAX InetPortNumber
         MAX-ACCESS read-only
         STATUS current
         DESCRIPTION
               "The UDP port the client is using to send requests
                to this server."
         REFERENCE "RFC 2865 section 3"
         ::= { radiusAuthServerExtEntry 4 }
or
      radiusAccClientServerInetPortNumber  OBJECT-TYPE
            SYNTAX InetPortNumber
            MAX-ACCESS read-only
            STATUS current
            DESCRIPTION
                  "The UDP port the client is using to send requests
                   to this accounting server."
            REFERENCE "RFC 2866 section 3"
            ::= { radiusAccServerExtEntry 4 }


I think I would make that
          SYNTAX     InetPortNumber (1..65535)
So that it is also determinable by machine that zero is invalid.
I know that I only pointed out that according to RFC 4001 you must state
what zero means. B ut if the value is not allowed, as I now understand it,
then I think using the SYNTAX I suggest is better.

Proposed Resolution: Accept
 


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