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

From: "Heintz, Lauren" <[email-masked]>
Date: Tue, 2 Mar 1999 13:25:38 -0600

Comments follow....

Lauren

> -----Original Message-----
> From: Mark Ellison [mailto:[email-masked]]
> general conmments:
> 
> - check capitalization on "AgentX".
>  The draft contains "Agentx", "AgentX", and "agentx".

Done.  Changed all non-object refs to "AgentX".

> p.7  agentxDefaultTimeout
> 
>  What are the semantics associated with a value of zero?
>  Would it be "don't timeout"?  Or would this attribute
>  be better defined with a range of 1..255?

Done.  0 now means "don't timeout".

> p.9  agentxConnTransportDomain
> 
>  Where are possible values listed?  A reference to an
>  RFC or Internet Draft might be good.

I've checked other SNMPv3 docs containing similar constructs and have not
found explicit references to any docs that contain possible TDomain values.
Indeed, the purpose of TDomain is to allow new (unanticipated) TDomain
values to be defined any time new standards are created without obsoleting
older ones.  It is thus very difficult to reference documents that haven't
been written yet.  :-)   Also, I think it was determined at the Chicago
AgentX WG that these new TDomain values would be defined within a separate
draft, proposed I think, by Mike D.  I'm not sure any possible values have
even been defined yet anyway.  However, if someone provides suggested text
regarding this issue, I will be happy to add it.

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

> p.11 agentxSessionObjectID
> 
>  Please add: "This attribute will report a
>  value "0.0" for subagents not supporting the
>  notion of an objectID.

Done.

> p.11 agentxSessionDescr
> 
>  Please add: "This attribute will report a value
>  a value of the zero-length string for subagents
>  not supporting the notion of a session description.

Done.

> p.12 agentxSessionAgentXVer
> 
>  Consider change from: "This will be less..."
>  to: "This must be less..."

Done.

> p.13 agentxRegisterDuplicate
> 
>  This attribute belongs in the AgentXRegistrationEntry,
>  and should be incremented whenever  a received registration
>  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.

> p.15 agentxRegPriority
> 
>  I think the WG had agreed upon using a default value for
>  this attribute- but forget if the actual value was 127
>  or 128...please state the default value for this attribute.

Done (127).

> p.18 Security Considerations
> 
>  This section might have to be revamped to the SNMPv3 template,
>  as this is what IESG seems to want these days.

I'll work on this and everyone will have a chance to review the security
modifications when I finish and re-post the draft to the list.

-------------------------------------------------------------------------
Lauren Heintz                 BMC Software, Inc. (Formerly PEER Networks) 
Voice: +1 408 616-3169        Silicon Valley Division 
Fax:   +1 408 616-3339        965 Stewart Drive 
Email: [email-masked]  Sunnyvale, California 94086 USA 
-------------------------------------------------------------------------

---

From: Mike Daniele <[email-masked]>
Date: Tue, 02 Mar 1999 15:04:13 -0500

Hi Lauren,

Thanks for the updates.

> regarding this issue, I will be happy to add it.

I agree there aren't RFCs to quote.  The values we need for AgentX
do have to be defined somewhere, and as you note we had talked about
doing that not in the AgentX MIB but in a different document.

The issue of what to use to represent general addresses has come up to IESG and I
think Bert is going to put it on the new list of things for the SNMPv3 WG to do
that aren't really SNMPv3.  Not sure if anything will happen soon enough to help us here.

> If likely or common, moving the duplicate variable to the entry may be

If session A registers foo then later session B also registers foo
and receives the duplicateRegistration error, then the MIB counter
in the AgentXRegistrationEntry corresponding to A's registration of
foo would be the one that gets bumped.  A doesn't need to adjust to anything.

That is, the object counts the number of times other registration requests
were refused as duplicates of this registration.

At least that's what I think would be useful.

Regards,
Mike

---

From: Bob Natale <[email-masked]>
Date: Tue, 02 Mar 1999 15:33:29 -0500

>At 3/2/99:03:04 PM, Mike Daniele wrote:

Hi Mike,

>Thanks for the updates.

Yes, thanks Lauren, we'll try to build some momentum
off of this now.

>> > p.13 agentxRegisterDuplicate
<...>
>That is, the object counts the number of times other registration
>requests were refused as duplicates of this registration.
>

Yep...that's my understanding too.

Cordially,

BobN
------------ ISO 9001 Registered Quality Supplier -----------
Bob Natale         | ACE*COMM              | 301-721-3000 [v]
Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f]
[email-masked]| Gaithersburg MD 20878 | www.acecomm.com
------------- Free downloads at www.winsnmp.com -------------