[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Review of RFC 3576 MIBs
Thank you very much Alan for your review. Please see inline for <Nagi>.
> -----Original Message-----
> From: firstname.lastname@example.org
> [mailto:email@example.com] On Behalf Of Alan DeKok
> Sent: Thursday, November 10, 2005 7:19 AM
> To: firstname.lastname@example.org
> Subject: Review of RFC 3576 MIBs
> 1) There are references to "Disconnect messages" and "CoA messages"
> radiusDynAuthClientCoAInvalidServerAddresses, and maybe others).
> While this terminology is used in RFC 3576, it would be good
> to be consistent with Section 3 of the document, the other
> MIB entries, and use "Disconnect-Request packet" and
> CoA-Request packet".
<Nagi> The DAC may receive Disconnect-Response packets. To make it
consistent with other four MIBs, we'll update with "Disconnect-Response
packets" and "CoA-Response packets". Please note that as you mentioned
Response packets are mentioned in RFC 3576 Section 2.2.
> See also radiusDynAuthServerDisconInvalidClientAddresses
> and radiusDynAuthServerCoAInvalidClientAddresses in the
> server MIB. The radiusDynAuthServDupDisconRequests refers to
> "Disconnect-Request packets", for example.
> 2) radiusDynAuthServerAddress has a description of "IP
> address value...", but it's missing a phrase used in the
> 26**bis documents:
> "..., , using the version neutral IP adddess format."
> See also radiusDynAuthClientAddress in the server MIB.
> I suggest adding that to be consistent with other RADIUS MIBs.
<Nagi> OK, we'll change.
> 3) Similarly, radiusDynAuthServerID talks about the
> NAS-Identifier, but is missing text that's in RFC 2619, and
> "This is not necessarily the same as sysName in MIB II."
> See also radiusDynAuthServerIdentifier in the server MIB.
> Question: Is this text relevant?
<Nagi> I guess this text means that it is a particular Radius
authentication/accounting/DynAuth client/server module name and could be
different from sysName. To make it consistent, we can also adopt that
> 4) radiusDynAuthClientMalformedCoAResponses talks about
> "CoA-Response packets", but no such packets are defined in
> RFC 3576 (barring a diagram on page 6). I would suggest
> using explicit "CoA-ACK" and CoA-NAK", but rfc2618bis uses
> "Access-Response" in the same manner.
> And the text in radiusDynAuthClientCoAPendingRequests uses
> "CoA-Ack, CoA -NAK" explicitly. (And there's an extra space
> in CoA-NAK)
> I'm not sure what to suggest here. Either leave it as-is,
> or change both this and rfc2618bis.
<Nagi> As I mentioned above, IMO, it is ok to have
Disconnect/CoA-Response packtes terminology and they are mentioned in
> See comments above. Also, page 4, references to
> [RFC2618bis] and [DYNCLIENT] don't have RFC editor notes to
> replace the text with the final RFC numbers. I don't know if
> such a note is necessary.
<Nagi> This makes sense otherwise how will the RFC editor know.
> Alan DeKok.
> to unsubscribe send a message to
> email@example.com 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 firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.