[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


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:dromasca@avaya.com]
*Sent:* Monday, December 20, 2004 15:39
*To:* radiusext@ops.ietf.org
*Cc:* bwijnen@lucent.com
*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