RE: Review of RFC 3576 MIBs

["Nagi Reddy Jonnala \(njonnala\)" <njonnala@cisco.com>]

Thank you very much Alan for your review. Please see inline for <Nagi>. 

> -----Original Message-----
> From: owner-radiusext@ops.ietf.org 
> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Alan DeKok
> Sent: Thursday, November 10, 2005 7:19 AM
> To: radiusext@ops.ietf.org
> Subject: Review of RFC 3576 MIBs
> 
> draft-ietf-radext-dynauth-client-mib-02.txt
> 
>   Nits:
> 
>  1) There are references to "Disconnect messages" and "CoA messages"
> (radiusDynAuthClientDisconInvalidServerAddresses,
> 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 
> rfc2619bis:
> 
> 	"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
text. 

> 
>  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
the diagram.

> 
> ---
> draft-ietf-radext-dynauth-server-mib-02.txt
> 
>   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. 

Thanks
Nagi.

>   Alan DeKok.
> 
> --
> 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/>