RE: REMINDER: RADEXT WG last call on RFC 2618bis-2621bis
"Romascanu, Dan \(Dan\)" <dromasca@avaya.com> Sun, 13 November 2005 22:47 UTC
Envelope-to: radiusext-data@psg.com
Delivery-date: Sun, 13 Nov 2005 22:48:29 +0000
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: REMINDER: RADEXT WG last call on RFC 2618bis-2621bis
Date: Mon, 14 Nov 2005 00:47:28 +0200
Message-ID: <AAB4B3D3CF0F454F98272CBE187FDE2F0979CEED@is0004avexu1.global.avaya.com>
Thread-Topic: REMINDER: RADEXT WG last call on RFC 2618bis-2621bis
Thread-Index: AcXi791SxGvY3h5yQJaxKiv2hdUYZQE8La3g
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: radiusext@ops.ietf.org
Cc: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
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/>
- RE: REMINDER: RADEXT WG last call on RFC 2618bis-… Romascanu, Dan (Dan)
- Re: REMINDER: RADEXT WG last call on RFC 2618bis-… Alan DeKok
- REMINDER: RADEXT WG last call on RFC 2618bis-2621… Bernard Aboba