Issue 148: Review of RFC2618bis-2621bis

["Bernard Aboba" <[e-mail]>]

>From: "Romascanu, Dan (Dan)" <[e-mail]>
>To: <[e-mail]>
>CC: "Wijnen, Bert (Bert)" <[e-mail]>
>Subject: RE: REMINDER: RADEXT WG last call on RFC 2618bis-2621bis
>Date: Mon, 14 Nov 2005 00:47:28 +0200
>
>At the request of the Operations and Management Area Director I read
>again the documents. Here are my findings:
>
>General
>
>1. It is bad to have the following defined in multiple documents:
>
>radiusMIB  OBJECT-IDENTITY
>           STATUS  current
>           DESCRIPTION
>                 "The OID assigned to RADIUS MIB work by the IANA."
>            ::= { mib-2 67 }
>
>
>radiusAuthentication  OBJECT IDENTIFIER ::= {radiusMIB 1}
>
>These should be defined in the MIB module in one document only, say
>draft-ietf-radext-rfc2618bis-01.txt and imported in the other MIB
>modules.
>
>I remember having made this comment previously ... Or maybe I am
>confusing?
>
>2. All MIB modules include deprecated IPv4 tables and new IPv4/IPv6
>tables. In the case when both the older deprecated IPv4 tables and the
>new IPv4 / IPv6 tables are supported in agents for backwards
>compatibility reasons, is there any relationship between the indexation
>of the two tables?
>
>3. What does the following text present in all documents mean?
>
>Managed entities SHOULD NOT instantiate the deprecated table
>    containing IPv4-only address objects when the RADIUS server address
>    represented in the table row is not an IPv4 address.  Managed
>    entities SHOULD NOT return inaccurate values of IP address or SNMP
>    object access errors for IPv4-only address objects in otherwise
>    populated tables.
>
>Does this mean that if there is at least one address that is not an IPv4
>address the whole deprecated table will not be implemented, or does this
>mean that only instances that do not correspond to IPv4 addresses are
>not implemented, but the table exists and includes rows only for IPv4
>instances?
>
>
>4. It would be helpful if UNITS clauses would be added where applicable
>to objects with a SYNTAX of Counter32
>
>5. It would be helpful if REFERENCE clauses would be added to the
>definition of objects that have a direct mapping on RFC 2865. For
>example the definition of the radiusAuthClientExtAccessRequests object
>in draft-ietf-radext-rfc2618bis-01.txt should include a REFERENCE clause
>that points to RFC 2865, Section 4.1.
>
>6. All MIB modules include objects that refer to malformed requests and
>malformed responses (radiusAuthClientExtMalformedAccessResponses,
>radiusAuthServTotalMalformedAccessRequests,
>radiusAuthServExtMalformedAccessRequests,
>radiusAccClientExtMalformedResponses, etc.). I could not find a
>definition of 'malformed' in RFC 2865.Some definitions refer to length,
>but the definitions need to be clear and consistent.
>
>7. As the documents define MIB modules referring to various aspects of
>the instrumentation of RFC 2865, and RFC 2866, I believe that one
>cannot implement these documents without understanding and implementing
>relevant portions of RFC 2865 or RFC 2866. In consequence, [RFC2865]
>should be Normative Reference for RFC 2618-bis and RFC 2619-bis and
>[RFC2866] should be Normative Reference for RFC 2620-bis and RFC
>2621-bis, rather than Informative.
>
>8. RFC 3411needs to be added to the Normative References because
>SnmpAdminString is imported from SNMP-FRAMEWORK-MIB
>
>9. The Security Considerations sections in the documents are not aligned
>with the latest boilerplate described in
>http://www.ops.ietf.org/mib-security.html.
>
>Specifically the last paragraph in each Section needs to be replaced
>with the following:
>
>It is RECOMMENDED that implementers consider the security features as
>    provided by the SNMPv3 framework (see [RFC3410], section 8),
>    including full support for the SNMPv3 cryptographic mechanisms (for
>    authentication and privacy).
>
>    Further, deployment of SNMP versions prior to SNMPv3 is NOT
>    RECOMMENDED.  Instead, it is RECOMMENDED to deploy SNMPv3 and to
>    enable cryptographic security.  It is then a customer/operator
>    responsibility to ensure that the SNMP entity giving access to an
>    instance of this MIB module is properly configured to give access to
>    the objects only to those principals (users) that have legitimate
>    rights to indeed GET or SET (change/create/delete) them.
>
>9. I believe that the DESCRIPTION clauses of the MODULE-COMPLIANCE
>modules need to be harmonized with the content of the sections
>describing the Deprecated objects. The DESCRIPTION of the deprecated
>module should mention that these modules are for IPv4 entities only,
>while the current modules support both IPv4 and IPv6.
>
>
>
>
>
>
>draft-ietf-radext-rfc2618bis-01.txt
>
>1. idnits has no problem with this I-D.
>
>2. smilint complains about:
>
>smilint -m -s -e -m -s -l 6 -i namelength-32 rfc2618bis.txt
>
>rfc2618bis.txt:15: [4] {module-identity-registration} warning:
>uncontrolled MODULE-IDENTITY registration
>
>This is because of the root registration issue that was discussed on the
>radext mailing list, and the WG decided to keep the root of the MIB
>modules under the administration of the WG, and not of IANA.
>
>I do not like this, but I can live with it.
>
>3. The acronym NAS shows up for the first time in Section 5 of the
>document without being expanded.
>
>4. Section 5 includes the following text:
>
>    Each entry in the RADIUS Authentication Server Table includes sixteen
>    columns presenting a view of the activity of the RADIUS
>    authentication client.
>
>Actually the first column is not-accessible, representing the index of
>the table. There are only fifteen accessible columns for each entry.
>
>
>draft-ietf-radext-rfc2619bis-01.txt
>
>1. idnits has no problem with this I-D.
>
>2. smilint complies about:
>
>smilint -m -s -e -m -s -l 6 -i namelength-32 rfc2619bis.txt
>
>rfc2619bis.txt:11: [4] {module-identity-registration} warning:
>uncontrolled MODULE-IDENTITY registration
>
>This is because of the root registration issue that was discussed on the
>radext mailing list, and the WG decided to keep the root of the MIB
>modules under the administration of the WG, and not of IANA.
>
>I do not like this, but I can live with it.
>
>3. The Abstract section should shortly define the scope of the MIB, and
>not only mentions that it updates RFC 2619.
>
>4. Section 5 includes the following text:
>
>Each entry in the RADIUS Authentication Client Table
>    includes thirteen columns presenting a view of the activity of the
>    RADIUS authentication server.
>
>One of the columns is actually an un-accessible index, so only twelve of
>the columns present a view of the activity of the clients.
>
>5. The statement made in the Security Consideration section that the MIB
>does not include any object with a read-write MAX-ACCESS is not
>accurate. The radiusAuthServConfigReset has a MAX-ACCESS of read-write,
>and the Security Consideration sections needs to include the description
>of the security hazards related to the intentional or non-intentional
>incorrect manipulation of this object, as well as the boilerplate text
>related to writeable objects.
>
>6. radiusAuthServConfigReset - is reset(2) the only writeable value for
>this object? If so, this needs to be mentioned in the DESCRIPTION
>clause, and the desired behavior of the agent if a different value is
>entered must be described.
>
>draft-ietf-radext-rfc2620bis-01.txt
>
>1. idnits has no problem with this I-D.
>
>2. smilint complies about:
>
>smilint -m -s -e -m -s -l 6 -i namelength-32 rfc2620bis.txt
>
>rfc2620bis.txt:16: [4] {module-identity-registration} warning:
>uncontrolled MODULE-IDENTITY registration
>
>I do not like this, but I can live with it.
>
>3. The Abstract section should shortly define the scope of the MIB, and
>not only mentions that it updates RFC 2619.
>
>4. The acronym NAS shows up for the first time in Section 5 of the
>document without being expanded.
>
>5. Section 5 includes the following text:
>
>Each entry in
>    the RADIUS Accounting Server Table includes fifteen columns
>    presenting a view of the activity of the RADIUS client.
>
>One of the columns is actually an un-accessible index, so only fourteen
>of the columns present a view of the activity of the clients.
>
>
>
>draft-ietf-radext-rfc2621bis-01.txt
>
>1. idnits complains about:
>
>tmp/draft-ietf-radext-rfc2621bis-01.txt(595): Line has weird spacing:
>'...invalid  authe...'
>tmp/draft-ietf-radext-rfc2621bis-01.txt(789): Line has weird spacing:
>'...invalid  authe...'
>
>2. smilint complies about:
>
>smilint -m -s -e -m -s -l 6 -i namelength-32 rfc2621bis.txt
>
>rfc2621bis.txt:13: [4] {module-identity-registration} warning:
>uncontrolled MODULE-IDENTITY registration
>
>I do not like this, but I can live with it.
>
>3. Section 5 includes the following text:
>
>Each entry in the RADIUS Accounting Client Table includes twelve columns
>    presenting a view of the activity of the RADIUS accounting server
>
>.One of the columns is actually an un-accessible index, so only eleven
>of the columns present a view of the activity of the clients.
>
>4. The statement made in the Security Consideration section that the MIB
>does not include any object with a read-write MAX-ACCESS is not
>accurate. The radiusAccServConfigReset has a MAX-ACCESS of read-write,
>and the Security Consideration sections needs to include the description
>of the security hazards related to the intentional or non-intentional
>incorrect manipulation of this object, as well as the boilerplate text
>related to writeable objects.
>
>
>Overall I believe that the documents are at in a reasonable shape. They
>can be forwarded to the IESG for consideration as Proposed or
>Informational, either with a list of known problems, or (better) after a
>short editing round to fix the problems detected during the WGLC.
>
>Regards,
>
>Dan
>
>
>
>
>
>
>
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]]On Behalf Of Bernard Aboba
> > Sent: Wednesday, November 02, 2005 16:57
> > To: [e-mail]
> > Subject: REMINDER: RADEXT WG last call on RFC 2618bis-2621bis
> >
> >
> > This is a reminder that RADEXT WG last call on RFC
> > 2618bis-2621bis is in progress.  These documents are being
> > considered as Proposed Standards (2618bis, 26819bis) and
> > Informational (2620bis, 2621bis). The documents are available
> > for inspection here:
> >
> > http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2618b
> > is-01.txt
> > (Proposed Standard)
> > http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2619b
> > is-01.txt
> > (Proposed Standard)
> > http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2620b
>is-01.txt
>(Informational)
>http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2621bis-01.txt
>(Informational)
>
>RADEXT WG last call will last until Monday, November 14, 2005. Please
>send comments to the RADEXT WG mailing list ([e-mail]) in
>the format described in the RADEXT Issues list:
>http://www.drizzle.com/~aboba/RADEXT/
>
>Note:  so far no WG last call comments have been received.  If you have
>read the documents, please respond to the WG last call, even if only to
>say "I am OK with them".
>
>
>
>--
>to unsubscribe send a message to [e-mail] 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 [e-mail] 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 [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>