Conference azur::mcc

    > What is the official supported wildcard level for multi-level
    > children?
    
    Wildcard rules are enforced (*if enforced*) by the access module,
    and/or the entity being managed, not the PM.  The AM best knows the
    capability of the entity it is managing.  If I remember right,
    the DNA4 AM will intercept a multiple wildcard request and reject it
    without sending a request to the node.  Probably because some
    implementations couldn't handle it.  Just a guess (I'm not even certain
    that it still filters multiwildcards).
    
    I believe the DNA5 AM used to do this and I relaxed that restriction
    some time ago and let the entity reject the request if it couldn't
    handle it.
    
    In your case, the node engr24 was given the request just as you
    specified it, and it rejected the request.  I know for sure 'cause
    I just sent it the exact request you placed in .-1.  What I got back
    was a CMIP Reject #34 "Invalid use of wildcard" with Wildreason code #4
    "wildcard not at lowest level".

Bummer, but thanks much for your reply. Unfortunately I don't know where to 
turn at this point. This appears to be another situation of collaboration 
between engineering groups which hasn't happened yet and I'm not sure who 
is best to ask for the change.

If I request this of the DECNIS folks they will most likely put this *very*
low on the priority list. If I ask for it from you folks to enhance the AM to
handle this it is unlikely to happen for a couple of reasons: a) this AM seems
to have a very low priority at this time and b) there may be technical reasons
(aside from being inefficient) why it can't or shouldn't be done. Also note
that both engineering groups will invest in SNMP upgrades but this doesn't help
today, maybe tomorrow (whenever that is).

So the situation we (those with many many links to manage) face is to either
create, maintain, and eat the resources for an alarm on every link; or create
an ncl script to do the polling, parsing, and send collector events. Each of
these approaches seems like it will be replaced by snmp in time, but how long.
It is likely we'll do the ncl scripts for ease of maintenance, unfortunately
this further reduces mcc's actual technical use. If life leads us to snmp, 
which looks likely, a new management strategy may evolve with the tools of our
business.

any advice or comments?
brad...

    > If I ask for it from you folks to enhance the AM to
    > handle this it is unlikely to happen for a couple of reasons
    
    Brad, The DNA5 AM *is* handling this today.  The _entity_ rejected the
    multiwildcarded request.
    
    John
    

hmmmm, the fog thins. I'll have to jump to the other conference to see if 
there is any future hope within CMIP or if SNMP is the only future focus.

thanks,
brad...

Out of  interest,  John,  why  did  you change the AM to pass it through? Is
there some implementation that does something useful with it?

The DNA  NETMAN architecture specifies that it is not valid to have multiple
levels of wildcards in management requests.  This was a deliberate decision:
it  was a case where we decided the directors (specifically MCC) should have
the  logic  to  handle this, instead of having to put it in every agent.  At
the  time  (1986?)  it  was  intended  that MCC would handle it (in the AM).
Since  then,  of  course, many things have changed.  You could try posting a
note  in the requirements conference suggesting that the DNA5 AM be enhanced
to impleent this.

Anyway, as you rightly guessed, this will not change on DECNIS.  I recommend
you  switch  to  PPP  which  does not have this problem (and also avoids the
window size problem which Easynet have been complaining about for years!).

Graham

>The DNA  NETMAN architecture specifies that it is not valid to have multiple
>levels of wildcards in management requests.  This was a deliberate decision:
>it  was a case where we decided the directors (specifically MCC) should have
>the  logic  to  handle this, instead of having to put it in every agent.  At
>the  time  (1986?)  it  was  intended  that MCC would handle it (in the AM).
>Since  then,  of  course, many things have changed.  You could try posting a
>note  in the requirements conference suggesting that the DNA5 AM be enhanced
>to impleent this.

Graham, thanks for answering directly within this note. I probably will
request for this support once I get a better understanding as to whether our
intentions are to really use cmip for the long term.

>Anyway, as you rightly guessed, this will not change on DECNIS.  I recommend
>you  switch  to  PPP  which  does not have this problem (and also avoids the
>window size problem which Easynet have been complaining about for years!).

Can't say we're quite ready to jump to PPP yet as a wholesale solution. We 
have no metrics reporting abilities for this to date. No metrics, can't manage, 
... can't manage, don't implement! Personally I'd also like to understand the 
_down_ side of not having the window. Dirty links might just cause a
different problem (bet on it). I'm told PA is working on stats but I haven't 
seen a timeframe for release as yet. Whichever way we turn there always seems
to be a gotcha. Nobody said it would be easy, and if it were, I'd be doin'
something else.

cheers,
brad...

> Out of  interest,  John,  why  did  you change the AM to pass it through?

Hi Graham,

It's been a while, but I think I relaxed the wildcard filter so that
common agent requests could make multi-wildcarded requests.
The VMS common agent uses the DNA5 AM as its transport.

There also was a bug in the validation of wildcarding in earlier versions
of the AM such that *all* directives were rejected if they had more than one
wildcard.  Well, some directives are for the director side only and can support
multi-wilds (read 'feature').  GETEVENT comes to mind.

So I think my thinking was that I could simplify the validation inside the AM
while allow entities which could handle multiple wildcarded requests to
receive it as such.  Entities which couldn't, simply rejected the request.

By the way, congrats on your promotion.  Well deserved.

John