Net manager view of entities (was Re: Implementation Experience

"Michael L. Kornegay" <mlk@bir.com> Fri, 12 March 1993 04:05 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16194; 11 Mar 93 23:05 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16190; 11 Mar 93 23:05 EST
Received: from SLEEPY.TIS.COM by CNRI.Reston.VA.US id aa02971; 11 Mar 93 23:05 EST
Received: from sleepy.tis.com by sleepy.TIS.COM id aa00483; 12 Mar 93 3:53 GMT
Received: from tis.com by sleepy.TIS.COM id aa00479; 11 Mar 93 22:44 EST
Received: from emory.mathcs.emory.edu by TIS.COM (4.1/SUN-5.64) id AA11704; Thu, 11 Mar 93 22:44:24 EST
Received: from bir.UUCP by emory.mathcs.emory.edu (5.65/Emory_mathcs.3.4.6) via UUCP id AA21009 ; Thu, 11 Mar 93 22:43:44 -0500
Return-Path: bir!mlk@bir.com
Received: by bir.bir.com (uA-1.5v4); Thu, 11 Mar 93 22:41:56 EST
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: "Michael L. Kornegay" <mlk@bir.com>
To: snmp-sec-dev@tis.com
Subject: Net manager view of entities (was Re: Implementation Experience
Date: Thu, 11 Mar 1993 22:41:56 -0500
Reply-To: mlk%bir.UUCP@mathcs.emory.edu
Message-Id: <0D15DDF1.sas5js@bir.bir.com>
X-Mailer: uAccess - Macintosh Release: 1.5v4

In Regards to your letter <938.726369559@dbc.mtview.ca.us>:

>      The separation of context from the destination party introduces a
>      very powerful notion for management stations: applications select
>      object resources that they want to manage (a context) and indicate
>      whatever communication requirements they have (i.e.,
>      authentication, privacy), and the next layer down selects the
>      parties, etc.  This means that users can now ignore parties and
>      deal solely with contexts.  For management stations trying to hide
>      complexity, this is a big win.

I am not sure I completely follow this...  I hope there is a nice abstraction
here.


In SNMPv1, an app would use (address,community) to indicate its target.

Do I understand the above to indicate that (context,authProt,privProt) is
enough and a reasonable way for SNMPv2 apps to indicate their target?  I
thought it would be (srcPty, dstPty, context).


The above says the next layer down can select the parties.  I probably do
not completely understand the Party MIB, but this doesnt seem that easy.

The following may illustrate my confusion:

  o Does the SNMPv2 Administrative Model require or imply that for any
    entries of the partyTable, contextTable, viewTable, and aclTable in
    the agent that those particular entries are needed in the manager in
    order to communicate with that agent?  Note that 3.1 of Administrative
    Model for SNMPv2 indicates no reference to viewTable or aclTable, but
    that contextTable contains a reference to viewTable impling its entry
    would need to be local.

  o Since consistancy is important, we probably should have included some
    form of party modification recording in the Party MIB so changes by
    other managers could be detected and updates of managers' local copies
    could be performed.  Such indication might have included a TimeStamp of 
    last sysUpTime when party mib was modified and possibly generate a 
    changed trap.

  o Do the comments in the origional message above imply that all party
    configurations will follow the conventions illustrated by the initial
    parties?  If this was so, I think the context abstraction presented
    may make sense.  However, it seems it could become complicated if other
    local strategies for defining parties are implemented.


Thanks,

----
mlk@bir.com, mlk@bir.uucp, or bir!mlk (Michael L. Kornegay)