Subject: Review of draft-ietf-agentx-rfc-update-01.txt

From: "Strahm, Bill" <[email-masked]>
Date: Tue, 28 Sep 1999 14:41:21 -0700

It looks good, I don't see any real reasons why this can not recycle at
proposed standard.

Now onto some nit picking
Issue 1:
I am very confused at a possible conflict between section 4.1 saying that
the role of the master agent is to  
" - Provides instrumentation for the MIB objects defined in RFC 1907 [17],
and for any MIB objects relevant to any administrative framework it
supports"
and later under 4.2 where it is said
"1) A general architectural division of labor between master agent and
subagent:  The master agent is MIB ignorant and SNMP omniscient, while ... "
(Ok I understand, but a little more clarification might be helpful)

Issue 2:
Page 11
last line is a header include, next page starts off with the definition...
can you  move the last line of page 11 down 
(I did say nits here)

Issue 3:
I would prefer having the AgentX PDU header (Section 6.1) placed before the
AgentX Encodings (Section 5)

Issue 4:
I would like railroad diagrams if possible for many of the Protocol
definitions, especially the SET PDUs to show what is passed and when. ( All
though the number of examples looks to be pretty good )

Issue 5:
page 34
definition of n.vb.
"-snmpTrapOID.0 must be present, as the second varbind if sysUpTime.0 was
supplied, as the first if it was not."
This seems to be cumbersome, of course I don't have any better wording :(

Issue 6:
7.1.4.1 Handling Duplicate and Overlapping Subtrees
An example here please, I think this is going to be an area of error ( real
implementors tell me if this isn't the case )
It also seems that if I register a less specific subtree, even if I have
priority 1, I will be taken over by a subAgent that registers a small subset
of my range...  Is this really the behaviour that we want ?

Issue 7:
7.1.4.2.2 Index Allocation
It doesn't look like AgentX is targetting MIBs where indexes are implemented
as TestandIncr variables.  I could see the need for a subagent to push
control of a TestandIncr variable to the Index Allocation routines... YMMV.
(PS good set of examples after this too)

Issue 8:
7.2.4 Subagent Processing of agentx-TestSet, -CommitSet, -UndoSet,
-CleanupSet-PDUs
Is there a time value that a subagent can use to cleanup after a TestSet is
performed if no other PDUs come from the Master Agent.  Or is this
implementation specific, if I don't see the next step in n amount of time,
ping the master agent and if it is still alive it will get around, if not,
then cleanup anyway ???

Issue 9:
7.2.4.1 Subagent Processing of agentx-TestSet-PDU
There has been a lot of talk on both the SNMPv3 list and here about this
issue.  I am not really certain that it has bottomed out, I will bow to
concensus of the WG to determine this (I am not sure I "FULLY" understand
the agruements Pro/Con)

Issue 10:
9 Security Considerations
Page 75
Why did you list the questions in one order, and answer them in the other
order, I think more than a simple "no" as the answer to question 2 is needed
(I know it is true however)

Also you recomend that the subagents run on the local host, but you have
defined a port (705) to potentially allow remote operation, is this an
inconsistancy ?

Bill
_____________________________________________
Bill Strahm        Programming today is a race between
bill.strahm@      software engineers striving to build
intel.com           bigger and better idiot-proof programs,
(503) 264-4632   and the Universe trying to produce
            bigger and better idiots.  So far, the
                        Universe is winning.--Rich Cook
I am not speaking for Intel.  And Intel rarely speaks for me

---

From: Mike Daniele <[email-masked]>
Date: Wed, 29 Sep 1999 09:31:24 -0400

Hi Bill,

Thank you for a timely review.  Some comments follow.

> (Ok I understand, but a little more clarification might be helpful)

I personally think what's there is just the right amount of detail.
I don't think we've had much confusion on this point, fyi.
But if you want to suggest some additional text, please do.

> implementors tell me if this isn't the case )

There is an example at the end of section 7.2.5.3 that goes into overlapping registrations
and who is authoratative.  This doesn't seem to have been confusing to implementors
from the feedback so far.  "Most specific wins" is common to existing non-AgentX
architectures.

> of my range...  Is this really the behaviour that we want ?

Yes!

> (PS good set of examples after this too)

Is that even permitted?  (An INDEX object with  read-write or read-create ACCESS?)

This would only be an issue if multiple subagents need to share such a table,
and hence register instances. (A single subagent implementing the table would simply register
the oid of the table.)  Further, since the subagents know what the value of their index objects is,
there would be no need to use AgentX index allocation.

(There would be AgentX registration considerations on the implementation.)

> ping the master agent and if it is still alive it will get around, if not,

Implementation-specific.  Could just do cleanup when you get the next AgentX
message, or ping as you've described.  But with connection-oriented transport under us,
if the master doesn't send anything you're probably going into "loss of link" mode
anyway.

> concensus of the WG to determine this (I am not sure I "FULLY" understand

I think Bob N answered this correctly.  If and when there is a change to 1905
(or anything else that affects us), we'll figure out what to do.

Actually I think Russ just declared this closed.

> order,

For artistic effect.  To highlight that the only control mechanism there is,
is on connection establishment.

> I think more than a simple "no" as the answer to question 2 is needed

Why?  Suggestions?

> defined a port (705) to potentially allow remote operation, is this an

No, some implementations may wish to use TCP,  we simply recommend
against it.  As such, it was the architecturally correct thing to register a port number.

(This is of major help during bakeoffs and remote testing.)

Regards,
Mike