RE: Conclusion of IETF Last call on RFC 3576 MIBs, RFC 2618bis-2621bis
"Bernard Aboba" <bernard_aboba@hotmail.com> Wed, 14 June 2006 18:15 UTC
Envelope-to: radiusext-data@psg.com
Delivery-date: Wed, 14 Jun 2006 18:15:27 +0000
Message-ID: <BAY106-F24FA519DFF4DF78500C5A5938D0@phx.gbl>
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: dnelson@enterasys.com, radiusext@ops.ietf.org
Bcc:
Subject: RE: Conclusion of IETF Last call on RFC 3576 MIBs, RFC 2618bis-2621bis
Date: Wed, 14 Jun 2006 11:15:13 -0700
Mime-Version: 1.0
Content-Type: text/plain; format="flowed"
Can we go ahead and issue new documents with these issues fixed? We could then ask the IESG to approve the documents. >From: "Nelson, David" <dnelson@enterasys.com> >To: <radiusext@ops.ietf.org> >Subject: RE: Conclusion of IETF Last call on RFC 3576 MIBs, RFC >2618bis-2621bis >Date: Wed, 14 Jun 2006 13:47:53 -0400 > >Bernard Aboba writes... > > > In order to enable IESG evaluation, we are requesting that > > the authors summarize the IETF last call comments and their > > responses to them on the RADEXT WG list. > >With regard to RFC 2618bis - 2621bis, there is one outstanding comment >from IETF Last Call, on RFC 2620bis and RFC 2621bis. > > >> 3) the accounting client MIB the first line of the MIB changed from > >> > >> RADIUS-ACC-CLIENT-MIB DEFINITIONS ::= BEGIN > >> > >> to > >> > >> RADIUS-ACCT-CLIENT-MIB DEFINITIONS ::= BEGIN > >> > >> (the T was added). Is this ok? > > > Ooops. No, it is not OK. This is a typo that will need to be > > corrected before the document is published as an RFC. Good catch. > > Everyone else, including me, has missed this so far. :-) > >Note that this change applies to both the RADIUS Accounting Client and >Server MIBs. > > >With regard to the RFC 3676 (Dynamic RADIUS) MIBs, Stefaan DeCnodder has >recently written, in response to a GetArt Review comment... > > >> - The client MIB contains a note to the RFC editor about the > >> reference [DYNSERV]. However, there is no such reference. > > > I checked it and the client MIB is OK, in the server MIB it seems > > that the RFC ed note is incorrect and [DYNSERV] should be replaced > > by [DYNCLNT]. The references in both of the drafts are correct, > > with the exception of the RFC ed note in the server MIB. > >With regard to the RFC 3676 (Dynamic RADIUS) MIBs, Stefaan DeCnodder has >recently written, in response to RADEXT Issue No. 193... > ><quote> > >* draft-ietf-dynauth-client-mib-06.txt > >1) issue 193: change SYNTAX of radiusDynAuthServerClientPortNumber from >"InetPortNumber" to "InetPortNumber (1..65535)" > > radiusDynAuthServerClientPortNumber OBJECT-TYPE > SYNTAX InetPortNumber (1..65535) > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The UDP destination port that the RADIUS Dynamic > Authorization Client is using to send requests to this > server. The value zero is invalid." > ::= { radiusDynAuthServerEntry 4 } > >2) remove radiusDynAuthClientCounterDiscontinuity as a scaler and put it >as last attribute in the table. Description has been updated slightly as >well as a small update in the conformance statement to reflect the move >of this attribute into the table. Also a small update of the overview >section that describes high level the scalars and table. > > radiusDynAuthClientCounterDiscontinuity OBJECT-TYPE > SYNTAX TimeTicks > UNITS "hundredths of a second" > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The time (in hundredths of a second) since the > last counter discontinuity. A discontinuity may > be the result of a reinitialization of the DAC > module within the managed entity." > ::= { radiusDynAuthServerEntry 32 } > >3) update date of draft and also inside the MIB > >* draft-ietf-dynauth-server-mib-06.txt > >1) remove radiusDynAuthServerCounterDiscontinuity as a scaler and put it >as last attribute in the table. Description has been updated slightly as >well as a small update in the conformance statement to reflect the move >of this attribute into the table. Also a small update of the overview >section that describes high level the scalars and table. > > radiusDynAuthServerCounterDiscontinuity OBJECT-TYPE > SYNTAX TimeTicks > UNITS "hundredths of a second" > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The time (in hundredths of a second) since the > last counter discontinuity. A discontinuity may > be the result of a reinitialization of the DAS > module within the managed entity." > ::= { radiusDynAuthClientEntry 27 } > >2) update date of draft and also inside the MIB > ></quote> > > >-- >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: Conclusion of IETF Last call on RFC 3576 MIBs… Bernard Aboba
- Re: Conclusion of IETF Last call on RFC 3576 MIBs… stefaan.de_cnodder
- RE: Conclusion of IETF Last call on RFC 3576 MIBs… Nelson, David
- RE: Conclusion of IETF Last call on RFC 3576 MIBs… Bernard Aboba
- RE: Conclusion of IETF Last call on RFC 3576 MIBs… Nelson, David
- Conclusion of IETF Last call on RFC 3576 MIBs, RF… Bernard Aboba