Subject: change log for updated RFC 2257

From: Mike Daniele <[email-masked]>
Date: Thu, 28 Jan 99 11:30:59 -0500

Hello,

Later today I'll be posting an updated version of RFC 2257.
Dale hasn't had a chance to go over it, so pagination, table of
contents, etc are not correct.

I apologize to all concerned for taking so long to get this out.

There aren't change bars, but I've included a log of changes
below.  This addresses (I believe) all the feedback we got
on the list and during/after the bakeoff.

It's worth noting that this is just about all clarification,
The only changes on the wire are

	o possibly new value to use as r.range_subid (depending
          on how you interpreted 2257)
	o Notify and Close PDUs generate responses
        o new error codes are available

Regards,
Mike

Change Log
----------

1) specifically defined "admin" pdu types vs "SNMP request processing"
   types in 6.1 h.type description.  use this distinction to update 
   res.sysuptime and res.error descriptions, and E of P.  

   SMIv2 error codes are NOT returned in responses to admin pdus.  
   (added noAgentXError (0) to make this distinction)

   Instances of "noError" are changed to "noAgentXError"
   everywhere appropriate.

2) res.error, added 

                parseFailed                (266),
                requestDenied              (267),
                processingError            (268)

   Added `requestDenied' to E of P for Register.

3) removed the text in 7. on parse errors and protocol errors.

4) added new "common processing" section to 7.1, which defines
   how to use parseFailed and processingError instead of closing
   a session, and how to handle context.

5) removed this common processing description from the other 
   admin pdu E of P and updated them to reference 7.1:

	o 7.1.2 index allocation
	o 7.1.4 index deallocation
	o 7.1.5 registration
 	o 7.1.6 unregister
	o 7.1.7 addagentcaps
	o 7.1.8 removeagentcaps
	o 7.1.9 close
	o 7.1.11 notify
	o 7.1.12 ping 

6) Reworked 7.1.1 (Open-PDU) to include new error codes,
   not refer to an indicated context, be tighter, etc,

7) modified E of P for Notify and Close PDUs to generate response PDUs.
   Notify also does context checking.

8) modified 6.2.3 (register pdu) to be clearer

	o new default priority of 127, and ptr to new
          section on how to register
	o better description of r.range_subid, independent of
          prefix in r.region
	o better description/examples of how this mechanism
          can be used.
	o added description for r.upper_bound (missing from rfc!)

        o changed r.region to r.subtree

          I did this because the text uses the terms region, range, 
	  and OID range too loosely.  this field is an Object Identifier.  
          It can't represent anything more by itself than a simple subtree.

          In conjunction w/ r.range_subid and r.upper_bound, it can
          represent a "region", that is a union of subtrees.

          Added much text about this and updated other areas of
          the spec accordingly.  See bullet 12.
 
9) modified 6.2.4 Unregister PDU to include descriptions of
   u.range_subid and u.upper_bound (missing from rfc!)

10) modified 7.1.6 E of P for Unregister to require a match
    also on u.range_subid and u.upper_bound (if present).

11) Changed 7.1.5.1 Handling Duplicate OID Ranges
    to say Handling Duplicate or Overlapping Subtrees, 
    and substantially modified the section

12) Removed all references to "splitting", and all uses 
    of the term "OID range".  OID range was used to mean
    the section of a r.subtree left after splitting, and
    was more confusing than useful.  Now just refer to 
    regions or subtrees directly, and let rule 1) in 7.2.1
    be enough for implementations to figure out their
    own "splitting" or other algorithms for doing it.

    This required modifications to 7.2.4.3.  Added new example.

13) In 7.2.1 removed the definition of "contains" because
    it is never used! :-)

14) Updated transport mappings to prohibit interleaved sends
    and added caution about receiving TCP.

15) Reworded 4.2 Applicability step 4).

    I've received several queries about why agentx
    "doesn't support ifTable"?  It actually does of course,
    what we were trying to acknowledge is row counters like
    ifNumber could be a problem.  

    So i separated the 2 things: row creation and counters
    that count rows.

16) Deleted 7.1.3 (Using IndexAllocate-PDU) and added
    7.1.5.2 Registering Stuff.  This is a hopefully more
    cohesive description of how things are supposed to work.

    Made clear the OID to allocate is an OBJECT-TYPE, does not
    contain instance subidentifiers.

    NOTE: We've had some discussion about multiply-indexed
    tables and can we support "tuples".  That is, session A
    allocates fooIndex value = 1 and barIndex value = 2.
    Session B wishes to allocate fooIndex value 1 and barIndex value 3.
 
   Currently this would fail.  I've left it this way, mainly
   because i couldn't think of a case where this is required AND
   one can't resonably assume the primary index values are known
   a priori or attainable without support in AgentX.

17) Added common processing for subagents in 7.2.2, and bumped
    all subsequent sections (get* processing became 7.2.3, etc.)

18) Replaced "subagent" with "session" in many places.

19) Cleaned up Test/Commit/Undo master processing to make it clear
    only "involved" sessions get Commit/Undos, not all of em, etc.
   
    Use "transaction" isntead of "packet" etc where appropriate to
    distinguish the overall transaction from particular packets/PDUs.
 
    Explicitly stated a session is not required to support concurrent sets.