Subject: Comments, questions related to section 7.1.5 of RFC 2257

From: [email-masked] (Sheldon Bishov, TCP/IP Services for OpenVMS, 978-506-5028, LKG1-3/L10)
Date: Mon, 14 Dec 1998 14:35:58 -0500 (EST)

Comments and questions on section 7.1.5 of RFC 2257.  Have checked
through the last year of archives, on the topic of duplicates saw only
Mike Daniele's comment about clarifying section 6.2.3 from Aug. 98.  
Any clarification or pointers to earlier discussions much appreciated.

Sheldon

------------------------------------

1. The flow of logic was hard to follow at first.  The "Otherwise" 
   in 5) is to match "If" in 3)?  The intervening step 4) threw me off:
   until I'd digested it:

...
   3) If the NON_DEFAULT_CONTEXT bit is set, and the master agent
      supports only a default context, the agentx-Response-PDU is
      returned with res.error set to `unsupportedContext', and the
      requested registration fails.  Otherwise:  The value of
      res.sysUpTime is set to the value of sysUpTime.0 for the indicated
      context.

   4) Characterize the request.
...
   5) Otherwise, if this is a duplicate registration, the
      agentx-Response-PDU is returned with res.error set to
      `duplicateRegistration', and the requested registration fails.
...

2. Verifying difference in behavior vs. DPI implementation:
   In the DPI implementation I'm familiar with, duplicate registration 
   is allowed; the later registration takes precedence (correct terminology: 
   "is the authoritative region"?).  In case the second subagent unregisters 
   the affected region (e.g., exits normally), the earlier registration 
   becomes active again.  Judging from description in 7.1.5, AgentX won't 
   allow this, correct?

3. The reason for subdivision of regions in the examples isn't clear.
   E.g., in the first example are subregions:

   1.3.6.1.2.1.4    up to but not including 1.3.6.1.2.1.4.22     (by S2)
   1.3.6.1.2.1.4.22 up to but not including 1.3.6.1.2.1.4.23     (by S2)
   1.3.6.1.2.1.4.22 up to but not including 1.3.6.1.2.1.4.23     (by S1)
   1.3.6.1.2.1.4.23 up to but not including 1.3.6.1.2.1.5        (by S2)

   Why is 1.3.6.1.2.1.4 up to but not including 1.3.6.1.2.1.4.23 split
   into two subregions?  Second example has similar case for
   1.3.6.1.2.1.4.23 up to but not including 1.3.6.1.2.2 .