Subject: RE: <draft-ietf-agentx-mib-03.txt> with change bars (RE-POST)

From: Randy Presuhn <[email-masked]>
Date: Fri, 5 Mar 1999 18:12:58 -0800 (PST)

Hi -

> From: "Heintz, Lauren" <[email-masked]>
> To: "[email-masked]'" <[email-masked]>
> Cc: "[email-masked]'" <[email-masked]>
> Subject: RE: <draft-ietf-agentx-mib-03.txt>   with change bars  (RE-POST)
> Date: Tue, 2 Mar 1999 13:25:38 -0600 
...
> > p.11 agentxSessionIndex
> > 
> >  I'd suggest "...its index should not be re-used..." be
> >  replaced with "...its index shall not be re-used...".
> >  Also, I have some difficulty understanding the last
> >  part of the last sentence, "...the values of
> >  agentxSessionIndex my be discontiguous and will not
> >  be the same for the same subagenet across multiple
> >  sessions."  Possibly the use of the word `session'
> >  is not the AgentX sense of session (something which
> >  is assigned an h.sessionID).  If that is what is
> >  going on here, probably change the last word in the
> >  sentence, from `sessions' to `invocations' or
> >  `process invocations' or something similar.
> 
> 
> I'm not even sure of the intended value of the last phrase of that sentence,
> so I propose to delete that confusing phrase so the sentence simply reads:
> "Note that if a subagent's session with the master agent is closed for any
> reason, its index shall not be re-used."
> 
> Done (pending objections to the above proposal).

I object.  "Shall" is the wrong word to use.  See RFC 2119 section 6.
Non-reuse of indexes is not required for the protocol to work.  However,
non-reuse is a good idea, but cannot be avoided if an agent stays up
long enough.  "Should" is the correct word.

...
> > p.13 agentxRegisterDuplicate
> > 
> >  This attribute belongs in the AgentXRegistrationEntry,
> >  and should be incremented whenever  a received registration

"should be" -> "is"

> >  is determined to be a `duplicate' of this region.
> >  Putting this attribute in the registration table would
> >  provide better information about registration "hot spots".
> 
> 
> I don't have a problem with this if no strong objections are heard.  Any
> objections?  However, considering that a given entry "belongs" to a given
> subagent, how likely is it that the given subagent may choose to disconnect
> (with the AgentxRegistrationEntry containing the incremented duplicate
> variable thus being deleted) rather than adjust to the failed registration.
> If likely or common, moving the duplicate variable to the entry may be
> undesirable.
...

It sounds like this behaviour would only be useful with extremely robust
(recovering from duplicate registration) or extremely sloppy (not checking
duplicate registration) subagents.  Those that just mutter "configuration
error" and quit would derive no benefit here.

 -----------------------------------------------------------------------
 Randy Presuhn           [email-masked]     http://www.bmc.com
 Voice: +1 408 616-3100  BMC Software, Inc.           965 Stewart Drive
 Fax:   +1 408 616-3101  Sunnyvale, California 94086  USA
 -----------------------------------------------------------------------
 Any relationship between my opinions and BMC's is coincidental.
 -----------------------------------------------------------------------