Subject: Re: Thanks & Confusion ........

From: Randy Presuhn <[email-masked]>
Date: Thu, 5 Aug 1999 14:04:51 -0700 (PDT)

Hi -

> Date: Thu, 05 Aug 1999 16:16:57 -0400
> From: Mark Ellison <[email-masked]>
> To: "Harrington, David" <[email-masked]>
> CC: [email-masked], "'agentx'" <[email-masked]>
> Subject: Re: Thanks & Confusion ........
> References: <[email-masked]>
> 
> Hi, David
> 
> Yes, the master agent determines the "authoritative region" and dispatches as
> you've described (essentially longest matching subtree, ties broken by priority
> value).
> 
> However, in your example, if the registration from S3 and S2 had the same
> priority and occurred in the order S1, S2, S3....Then S3 would be rejected as a
> duplicate of S2.  The registrations of S1 and S2 (alternatively S1 and S3) are
> overlapping.
...
> > S2 registers 1.2.3.[4-6]
> > S3 registers 1.2.3.4.5
...

It depends on which document you're looking at.

On page 48 of RFC 2256, in (4) of clause 7.1.5, the logic in the first
two paragraphs will result in Dave's S2 and S3 registrations being
classified as overlapping registrations, since its r.region and r.range
elements are not exactly the same as any registered r.region value.
This leads to a bit of trouble in clause 7.2.1 (1) and 7.1.5.1, in part
because the VACM tie-breaking technique is not used here.  (RFC 2575 says:
"If multiple entries match and have the same number of sub-identifiers
(when wildcarding is specified with the value of vacmViewTreeFamilyMask),
then the lexicographically greatest instance of vacmViewTreeFamilyType
determines the inclusion or exclusion.")

This is different in draft-ietf-agentx-rfc-update-00.txt, where the
requests could still be disambiguated if the values supplied for the
r.priority element differ, but must be rejected otherwise.

 ------------------------------------------------------------------------
 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 probably coincidental.
 ------------------------------------------------------------------------

---

From: Bob Natale <[email-masked]>
Date: Thu, 05 Aug 1999 17:53:45 -0400

>At 8/5/99:05:04 PM, Randy Presuhn wrote:

Hi Randy,

>It depends on which document you're looking at.

For sure...however, just so there is no doubt on the list:

<...>
>r.priority element differ, but must be rejected otherwise.

Right...and it is this document (and its imminent final edit before
IESG last call) that we are now looking to for guidance.  So, as you
suggest, Mark's answer is correct in accordance with this document.

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

---

From: Mark Ellison <[email-masked]>
Date: Thu, 05 Aug 1999 17:56:34 -0400

Hi, Randy

I find your reference to 2575 of great interest (...work at hand :-)

I've re-read RFC 2257, sxn 7.1.5 (4).  My interpretation still comes up as
'duplicate', not 'overlapping'.  Specifically, the first paragraph of RFC 2275, sxn
7.1.5. (4) says:

      If r.region (or any of its set of Object Identifiers, if r.range
      is non-zero) is exactly the same as any currently registered value
      of r.region (or any of its set of Object Identifiers), this
      registration is termed a duplicate region.

Would you interpret this "operative text" differently?  I also think the distinction
of 'dulplicate' and 'overlapping' was maintained across 2257 to rfc-update-00.

Thanks for close reading of 2275 and rfc-update-00!

Regards,

Mark

Randy Presuhn wrote:

> [deletions]