review of draft-decnodder-radext-dynauth-server-mib-02.txt

["Romascanu, Dan \(Dan\)" <[e-mail]>]

At the request of the Operations and Management Area Director I reviewed draft-decnodder-radext-dynauth-server-mib-02.txt. Please find below my comments. 

Regards,

Dan


1. The boilerplate does not conform with the latest recommendations referring to Intellectual Property notices. See http://www.ietf.org/ietf/1id-guidelines.txt for the mandatory notices. 
2. The Introduction section contains un-expanded acronyms which are not public domain knowledge for the Internet community - CoA, NAS.  
3. Section 5 in this document duplicates much of the similar section 5 in draft-decnodder-radext-dynauth-client-mib-02.txt. It may be better to avoid duplication by having the respective text be written only in one document and referred by the other. 
5.Is this MIB module implemented in conjunction with other MIB modules - for example those defined in RFC 2618 through 2621? If this is the case, this relationship should be discussed in one of the 'narrative' sections - probably in Section 5. The current text says no more than 'this memo ... relates to the following document...' which is un-sufficient and incorrect grammatically, and a list of multiple documents (plural) follows. 
6. Usage of radiusMIB root. As clarified by the Area Director doing a separate subtree for each technology is discouraged. 
So 
radiusDynamicAuthorization OBJECT IDENTIFIER ::= { radiusMIB 3 } 
is not good. We'd rather see: 
radiusDynamicAuthorization OBJECT IDENTIFIER ::= { mib-2 xxx } -- xxx to be assigned by IANA 
The reason is that we have run into clashed (i.e. conflicting definitions) when WGs try to keep track of registrations underneath a MIB branch. See also the recommendation in MIB review guidelines draft-ietf-ops-mib-review-guidelines-03.txt sect 4.5, 3rd bullet. So pls go for assignment under mib-2. If you want to stick it under radiusMIB, then you need to write a document similar to RFC3737.
7. There is a need for a RFC Editor note after "Initial version as published in RFC XXXX"
8. What is the purpose of the radiusDynAuthServerIdentifier object? If this is about software versions, application names, etc. there are objects in other MIB modules already defining this - see for example RFC 2737. If there is a something specific about a RADIUS dynamic authentication server identifier, some more information is needed - for example provide a reference to a 'NAS-Identifier'. 
9. DESCRIPTION clause of radiusDynAuthServerEntry - change '...representing the Dynamic...' with '...representing one Dynamic...'
10. DESCRIPTION clause of  radiusDynAuthServerCoAPacketsDropped - I suggest to add '...by the client application' after 'silently discarded'. 
11. I suggest to add UNITS clauses to the counter objects - messages, packets, retransmissions, etc. 
12. Section 9.1 - I wonder if references to RFC 2618 through 2621 are really normative references. I do not see the strong dependence on these specifications that would justify it.
13. There is no IANA Consideration section. Even if no actions are required from IANA, such a section must be present and just mention this
14. idnits complains about a weird spacing problem in line 605  '... client with ...'