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

[[e-mail]]

Hi Dan,

Sorry for the late response. Thanks for your review. All your comments 
will be taken into account in the next version of the draft. See below 
for some comments...


Wijnen, Bert (Bert) wrote:

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

see Bert's response: the MIB will be put under mib-2.


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

In fact, we took this object (together with 
radiusDynAuthServerIdentifier in 
draft-decnodder-radext-dynauth-client-mib-02.txt) from RFC 2618 through 
RFC 2621 where you also find these objects for authentication 
server/client and accounting server/client. I am not sure what the WG 
intent to do in the revision of these MIBs (as far as I know only 
updating with IPv6 support). If RFC2618-2621 keeps them, it might be 
better also to keep them here to make it consistent. 
radiusDynAuthServerIdentifier is the NAS identifier of the DynAuth 
server, i.e. based on this value, the DynAuth client can identify the NAS.


>     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?
> 

Agreed, I will add an initial value in the description for the 
non-trivial cases (seems to be that radiusDynAuthClientRoundTripTime is 
the only non-trivial case).


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

yes, it is better to make them Informative because the MIBs are 
independent from each other. It is very likely that for instance a NAS 
implements all MIBs together but that does not mean that they are 
dependent from eachother.

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

IANA considerations will be added.

thanks for the comments, for the other comments above, I agree on them.

regards,

Stefaan