RE: Comments on draft-decnodder-radext-dynauth-client-mib-02.txt

["Wijnen, Bert (Bert)" <[e-mail]>]

Thanks for the review Dan.
 
Let me add w.r.t. point 6
 
We do not like the idea of doing a separate subtree for each technology.
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 I'd like to see a document similar
to  RFC3737.
 
Bert
 
 -----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[e-mail]]
Sent: Monday, December 20, 2004 15:39
To: [e-mail]
Cc: [e-mail]
Subject: Comments on draft-decnodder-radext-dynauth-client-mib-02.txt



At the request of the Operations and Management Area Director I reviewed draft-decnodder-radext-dynauth-client-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 <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-server-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. 

4. Section 5, first paragraph - 'The RADIUS dynamic authorization extensions ... distinguishes...' - grammar problem

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. 

6. radiusMIB is already defined in other documents - see for example RFC 2619 -  RADIUS-AUTH-SERVER-MIB - I suggest that it is imported from there. 

7. What is the purpose of the radiusDynAuthClientIdentifier 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 client identifier, some more information is needed. 

8. DESCRIPTION clause of radiusDynAuthServerEntry. I suggest to say 'representing one Dynamic...' instead of 'representing the Dynamic...'.

9. The DESCRIPTION clause of radiusDynAuthServerIndex should be clear in saying that this number is allocated by the agent implementing this MIB module, and unique in this context (and not for an admin domain)

10. Add REFERENCE clauses for objects defining NAS attributes from RFC 2865, 2869, 3162 - ‎from case to case

11. DESCRIPTION clause of radiusDynAuthClientRoundTripTime - this should be defined as the time between sending a Disconnect or CoA request and the reception of a corresponding Disconnect-reply/CoA-reply 

12. what are the values of the objects in the radiusDynAuthServerEntry that depend on processing replies like radiusDynAuthClientRoundTripTime before a first reply is received from the server? For example what will be returned by an agent implementing this MIB module for radiusDynAuthClientRoundTripTime before a first reply is received and a meaningful round trip delay can be presented? 

13. DESCRIPTION clause of  radiusDynAuthClientDisconPacketsDropped - I suggest to add '...by the client application' after 'silently discarded'. 

14. same for radiusDynAuthClientCoAPacketsDropped

15. I suggest to add UNITS clauses to the counter objects - packets, retransmissions, etc. 

16. Section 7, 4th paragraph - should be 'These' rather than 'this' because the phrase refers to the two objects above

17. 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.

18. There is no IANA Consideration section. Even if no actions are required from IANA, such a section must be present and just mention this.