[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: REMINDER: RADEXT WG last call on RFC 2618bis-2621bis
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: owner-radiusext@ops.ietf.org
> [mailto:owner-radiusext@ops.ietf.org]On Behalf Of Bernard Aboba
> Sent: Wednesday, November 02, 2005 16:57
> To: radiusext@ops.ietf.org
> 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 (radiusext@ops.ietf.org) 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 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/>