[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00

              Local Processing Model for the Next Generation
                Simple Network Management Protocol (SNMPng)

                            26 March 1997


                              B. Wijnen
                       IBM T.J. Watson Research
                          wijnen@vnet.ibm.com

                            D. Harrington
                        Cabletron Systems, Inc.
                          dbh@cabletron.com


                    <draft-ietf-snmpv3-lpm-00.txt>


                          Status of this Memo

This document is an Internet-Draft.  Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups.  Note that other groups may also distribute
working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as ``work in progress.''

To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow
Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe),
ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).



                          Abstract

This document describes the Local Processing Model (LPM) for the
Next-Generation of the Simple Network Management Protocol (SNMPng).
It is part of the overall Architectural Model for the Next Generation
Simple Network Management Protocol (SNMPng).

This document includes a MIB for remotely monitoring/managing the
configuration paramters for this LPM.








Wijnen/Harrington         Expires September 1977               [Page  1]

Draft          Local Processing Model (LPM) for SNMPng        March 1997


0.  Change Log

[version 0.6]
  - Add address info for WG chair.
  - Add address for DaveH in MIB description
  - submit as I-D

[version 0.5]
  - Some more comments by BW.
  - Some more cleanup
  - Address comments from others (dbh, dl)
  - complete missing sections
  - I still have quite a few of editor's notes so that
    people can discuss/evaluate the alternatives.
    Or do we want/need to take a position right now?
  - add abstract
  - prepare for pagination

[version 0.4]
  - Add initial config info as appendix A
  - Some more cleanup

[version 0.3]
  - Explain and extend usage of viewTable and subtreeFamilyTable

[version 0.2]
  - merge in dbh comments
  - add more personal bw comments
  - add more terminology definitions
  - add MIB

[version 0.1]
  - initial version





















Wijnen/Harrington         Expires September 1977               [Page  2]

Draft          Local Processing Model (LPM) for SNMPng        March 1997


1.  Introduction

A management system contains: several (potentially many) nodes, each
with a processing entity, termed an agent, which has access to
management instrumentation; at least one management station; and, a
management protocol, used to convey management information between the
agents and management stations.

Management stations execute management applications which monitor and
control managed elements.  Managed elements are devices such as hosts,
routers, terminal servers, etc., which are monitored and controlled
via access to their management information.

Operations of the protocol are carried out under an administrative
framework which defines minimum policies for mechanisms which
provide message-level security, access control for managed objects,
and interaction between the protocol engine and the applications
which use the services of the engine.

The Architectural Model for SNMPng [SNMPng-ARCH] describes
a Local Processing Framework for SNMP messages that are
targetted for local processing to access management information or
for SNMP messages that originate from local processing of management
information.

It is the purpose of this document to define a Local Processing
Model (LP-M) for the Next Generation Simple Network Management
Protocol (LP-M for SNMPng).

1.1  Terminology

Definition of SNMPng acronyms and terms:

   MPC-F   - Message Processing and Control Framework
   MPC-M   - Message Processing and Control Model
   MPC-I   - Message Processing and Control Implementation

   SF-F    - Security Framework
   SF-M    - Security Framework Model
   SF-I    - Security Framework Implementation

   LP-F    - Local Processing Framework
   LP-M    - Local Processing Model
   LP-I    - Local Processing Implementation

   LCD     - Local Configuration Datastore

1.2  Local Processing

Local Processing may occur in an SNMPng entity acting in an agent
role in response to SNMPng request messages from an SNMPng



Wijnen/Harrington         Expires September 1977               [Page  3]

Draft          Local Processing Model (LPM) for SNMPng        March 1997


entity acting in a manager role.  These request messages include
several types of operations, including GetRequest, GetNextRequest,
GetBulkRequest, and SetRequest operations.

Local Processing only occurs if the request is targeted at local
management information as determined by the contextID in the
Naming-Scope in a Scoped-PDU. It is the MPC implementation (MPC-I)
that determines if the contextID refers to the current SNMPng
engine and if so, to direct the Scoped-PDU to the LP-I.

Local Processing almost always results in the production
of a response, (sometimes including error or other exceptional
indicators), termed the Response-PDU.

Local Processing can also result in the production of an
error report, termed the Report-PDU.

Local Processing is also responsible for generating notifications,
which will result in the production of one or more traps, termed
SNMPv2-TRAP-PDUs.

1.3  Local Configuration Datastore

To implement the model described in this document, each SNMPng
entity needs to retain its own set of information about access
rights and policies, trap destinations, and the like.  This set
of information is called the SNMPng entity's Local Configuration
Datastore (LCD) because it is locally-stored information.

In order to allow an SNMPng entity's LCD to be remotely configured,
portions of the LCD need to be accessible as managed objects.
A MIB module, the SNMPng LP-M Configuration MIB, which defines
these managed object types is included in this document.





















Wijnen/Harrington         Expires September 1977               [Page  4]

Draft          Local Processing Model (LPM) for SNMPng        March 1997


2.  Elements of the Model

This section contains definitions to realize the access control
applied by this LP-M.

2.1  SNMPng Group

A groupName identifies a group (set) of zero or more security
entities on whose behalf SNMP messages are being processed or
generated.
It is the responsibility of the MPC-I to determine in an
authorirative manner for which groupName an incoming SNMP
message is being processed.
It is the responsibility of the LP-I to determine the groupName
for which a notification (TRAP) is being generated.

This Model (LP-M) requires the groupName to be passed as input
to an implementation (LP-I) of this LP-M when a message is
handed to the LP-I for processing.

This Model (LP-M) requires the groupName to be passed as output
from an implementation (LP-I) when a message originates from
the LP-I.

2.2  SNMPng Quality of Service (Qos)

The Qos identifies the Quality of Service (in terms of message
security) used for transmitting the SNMP message.
It is the responsibility of the MPC-I to determine in an
authoritative manner the Qos that was used for an incoming
SNMP message.
It is the responsibility of the LP-I to determine the Qos
that must be used when transmitting a notification (TRAP).

This Model (LP-M) recognizes three different Qos levels:

   - without authentication and without privacy

   - with authentication but without privacy

   - with authentication and with privacy

This Model (LP-M) requires the Qos to be passed as input
to an implementation (LP-I) of this LP-M when a message is
handed to the LP-I for processing.

This Model (LP-M) requires the Qos to be passed as output
from an implementation (LP-I) when a message originates from
the LP-I.

2.3  Contexts



Wijnen/Harrington         Expires September 1977               [Page  5]

Draft          Local Processing Model (LPM) for SNMPng        March 1997



An SNMP context is a collection of management information
accessible by an SNMP agent.  An item of management information
may exist in more than one context.  An SNMP agent potentially
has access to many contexts.

2.4  SNMPng Scoped-PDU

A scoped-PDU contains a Naming-Scope that unambiguously
identifies an SNMP agent and the context, (locally) accesible
by that agent, to which the SNMP management information
in the SNMP-PDU refers.

A Naming-Scope contains a contextID that unambiguously identifies
the SNMP agent which has (local) access to the management
information refered to by the contextName and the SNMP-PDU.

A Naming-Scope contains a contextName which unambiguously
identifies an SNMP context accessible by the SNMP agent to
which the SNMP-PDU is directed or from which the SNMP-PDU
is originated.

It is the responsibility of the MPC-I to determine in an
authoritative manner if the contextID refers to the current
SNMPng engine and if so to direct the SNMP message to the
LP-I for local processing.

It is the responsibility of the LP-I to determine the
contextName from which the management information in a
notification (TRAP) is retrieved.

This Model (LP-M) requires the Soped-PDU to be passed as input
to an implementation (LP-I) of this LP-M if a message is
handed to the LP-I for processing.

This Model (LP-M) requires that the contextName be passed
as input to an implementation (LP-I) of this LP-M if a trap
must be generated.

This Model (LP-M) requires the Soped-PDU to be passed as output
from an implementation (LP-I) if a message originates from
the LP-I.

Editor's notes:
         I wonder if it would not be better to not use a
         Scoped-PDU as input/output to the LP-M but instead
         use contextName plus PDU as input/output. After all,
         the contextID is irrelevant in the LP-M and is in
         fact only used/known in the MPC.
End Editor's notes.




Wijnen/Harrington         Expires September 1977               [Page  6]

Draft          Local Processing Model (LPM) for SNMPng        March 1997


2.5  Access Policy

The access policy of this LP-M determines the access rights of
groups (representing zero, one or more security entities which
have the same access rights).  For a particular context
(contextName) to which a group (groupName) has access using
a particular Qos, that group's access rights are given by a
list of authorized operations, and a read-view and a write-view.
The read-view is the set of object instances authorized
for the group when reading objects.  Reading objects occurs
when processing a retrieval (Get, GetNext, GetBulk) operation
and when sending a notification (Trap).
The write-view is the set of object instances authorized for
the group when writing objects.  Writing objects occurs when
processing a Set operation.

2.6.  Error Reporting

Editor's notes:
         (additional) pieces of this should be specified
         in the MPC-M and SF-M
End Editor's notes.

While processing a received communication, an SNMPng entity may
determine that the message is unacceptable.  In this case,
the appropriate error counter is incremented and the received
message is discarded without further processing.

If an SNMPng entity is processing a received Get, GetNext,
GetBulk, Set or Inform PDU and determines that a message is
unacceptable and the reportableFlag indicates that a report
may be generated, then after incrementing the appropriate
counter, it is required to generate a message containing a
report PDU, with the same context as the received message,
and to send it to the transport address which originated
the received message.  For all report PDUs, generated by
the LP-I, the Qos for sending the report-PDU is set to
noAUth (no authentiocation, no privacy).

The reportableFlag should never be set for a message that
contains a Response, SNMPv2-Trap or Report operation.













Wijnen/Harrington         Expires September 1977               [Page  7]

Draft          Local Processing Model (LPM) for SNMPng        March 1997


3.  Elements of Procedure

This section describes the procedures followed by an
implementation (LP-I) of this Model (LP-M) when processing or
generating a Scoped-PDU

3.1  Processing a Received Scoped-PDU

This section describes the procedure followed by an implementation
(LP-I) whenever it receives a scoped-PDU for local processing.
This procedure is independent of any of the other processing
within the SNMPng Architectural Model.

(1)  The PDU portion of the Scoped-PDU is processed.  If the
     serialized PDU value is not the serialization (according to
     the conventions of [RFC1906]) of a PDU value, then the
     snmpInASNParseErrs counter [RFC1907] is incremented,
     and the received scoped-PDU is discarded without further
     processing.

(2)  The SNMPv2 operation type is determined from the ASN.1 tag
     value associated with the PDUs component.

(3)  If the SNMPv2 operation type is either a Report, Response,
     Trap, or Inform operation,
     then the snmpNgLpmStatsUnauthorizedOperations counter is
     incremented, and the received Scoped-PDU is discarded
     without further processing.

Editor's notes:
         the above PDU-types should not be passed to the LP-I.
         So it seems that the MPC-M also must define some SNMP
         PDU processing for Report, Response, Trap, Inform.

         We used UnauthorizedOperations counter in v2u but v2*
         used authorizationError (in SNMP PDU)... The v2u did that
         because it was part of the access-control as opposed to
         part of PDU processing. Now it seems part of PDU
         processing again...  so maybe using authorizationError
         is OK again... that is if we get to this point.
         If the MPC-I detects it, then it should be an
         unauthorizedOperations-report I think.
End Editor's notes.

(4)  The LCD is consulted for information about the SNMPng context
     identified by the contextName.  If information about this
     SNMPng context is absent from the LCD, then the
     snmpNgLpmStatsUnknownContexts counter is incremented, a report
     PDU [RFC1905] is generated, and the received scoped-PDU is
     discarded without further processing.




Wijnen/Harrington         Expires September 1977               [Page  8]

Draft          Local Processing Model (LPM) for SNMPng        March 1997


Editor's notes:
         The above means we have a contextTable within LPM,
         but I am not sure we need one... since we just use a
         contextName as an index into the snmpNgLpmAcTable.
         We already decided to get rid of contextLocalEntity.
         I have heard many stories that contectLocalTime is not
         used and that the functionality could be achieved by
         just defining few extra objects for those that need
         something like a value to be used at restartTime.

         If we do not use a contextTable, then we could check that
         the context is used as index in the acTable and if not,
         then we assume the context does not exist

         An other alternative is to skip step (4) and (5) and
         just return an authorizationError or a reportPDU for
         snmpNgLpmUnAuthorizedOperations since we will not find
         an entry in the snmpNgLpmAcTable.

         Some feel that the contextTable must exist (that is in
         readOnly mode) so that a manager can learn about the
         contextNames that exist at an agent.
         But the entityMIB also sort of defines logical entities
         which basically map to contextNames. However, the current
         entityMIB does not yet address SNMPng contexts. Maybe
         we should sync up with them.
End Editor's notes.

(5)  The LCD is consulted for information about the SNMPng group
     identified by the groupName.  If information about this
     SNMPng group is absent from the LCD, then the
     snmpNgLpmStatsUnknownGroups counter is incremented, a report
     PDU [RFC1905] is generated, and the received Scoped-PDU is
     discarded without further processing.

Editor's notes:
         The above would assume that we just check if the group
         is used as an index in the snmpNgLpmAcTable at all

         An other alternative is to skip step (4) and (5) and
         just return a authorizationError or a reportPDU for
         snmpNgLpmUnAuthorizedOperations since we will not find
         an entry in the snmpNgLpmAcTable.
End Editor's notes.

(6)  If the SNMPv2 operation type is either a Get, GetNext, GetBulk,
     or Set operation, then:

     a) the LCD is consulted for access rights authorized for
        communications using the indicated Qos, on behalf of the
        indicated group, and concerning management information in



Wijnen/Harrington         Expires September 1977               [Page  9]

Draft          Local Processing Model (LPM) for SNMPng        March 1997


        the indicated context for the particular SNMPv2 operation
        type.

     b) if the SNMPv2 operation type is not among the authorized
        access rights, then the snmpNgLpmStatsUnauthorizedOperations
        counter is incremented, a report PDU is generated, and
        the received Scoped-PDU is discarded without further
        processing.

     c) the management operation represented by the SNMPv2 operation
        type is performed by the receiving LP-I with respect to the
        relevant MIB view within the SNMPng context according to
        the procedures set forth in [RFC1905], where the relevant
        MIB view is determined according to the contextName,
        groupName and the Qos values and the SNMPv2 operation
        type requested.

     d) An SNMPv2 Response-PDU is produced and presented to the
        the MPC-I for further processing.
        The LP-I uses the scoped-PDU-MMS to ensure that the
        produced Response-PDU does not exceed the maximum
        message size.


3.2  Generating a Notification

This section describes the procedure followed by an implementation
(LP-I) whenever it must generate a Scoped-PDU for an SNMPv2-Trap.
This procedure is independent of any of the other processing
within the SNMPng Architectural Model.

(1)  The LCD is consulted for the set of trap destinations.

(2)  For each element in the set of trap destinations, the Qos,
     group (snmpNgLpmTrapGroup), destination addres and security
     model (snmpNgLpmSecModel) are extracted from the LCD and
     used together with the contextName in the following steps:

     a) the LCD is consulted for access rights authorized for
        communications using the indicated Qos, on behalf of the
        indicated group, and concerning management information in
        the indicated context for the SNMPv2 trap operation.

     b) if the SNMPv2 trap operation is not among the authorized
        access rights, then no SNMPv2-TRAP PDU is produced and
        processing continues with the next element.

     c) the varBindList is checked against the relevant MIB view
        where the relevant MIB view is determined according to the
        contextName, groupName and the Qos values and the SNMPv2
        trap operation.



Wijnen/Harrington         Expires September 1977               [Page 10]


Draft          Local Processing Model (LPM) for SNMPng        March 1997



     d) if any varBind is not in view, then no SNMPv2-TRAP PDU is
        produced and processing continues with the next element.

     e) an SNMPv2-TRAP PDU is produced and presented to the
        MPC-I for further processing. The LP-I passes the
        the Scoped-PDU, security model, the Qos, the groupName
        and the destination address to the MPC-I.














































Wijnen/Harrington         Expires September 1977               [Page 11]


Draft          Local Processing Model (LPM) for SNMPng        March 1997


4.  Definitions

SNMPng-LP-MIB DEFINITIONS ::= BEGIN

IMPORTS
    Counter32, Unsigned32,
    MODULE-IDENTITY, OBJECT-TYPE, snmpModules  FROM SNMPv2-SMI
    TEXTUAL-CONVENTION, TestAndIncr,
    RowStatus, AutonomousType, StorageType,
    TDomain, TAddress                          FROM SNMPv2-TC
    MODULE-COMPLIANCE, OBJECT-GROUP            FROM SNMPv2-CONF,
    SnmpNgGroupName, SnmpNgContextName,
    SnmpNgQos, SnmpNgEngineID,
    SnmpNgSecurityModel                        FROM SNMPng-MIB;


snmpNgLpMIB MODULE-IDENTITY
    LAST-UPDATED "9703260000Z"     -- 26 Mar 1997, midnight
    ORGANIZATION "SNMPv3 Working Group"
    CONTACT-INFO "WG-email:   snmpv3@tis.com
                  Subscribe:  majordomo@tis.com
                              In msg body:  subscribe snmpv3

                  Chair:      Russ Mundy
                              Trutsed Information Systems
                  postal:     3060 Washington Rd
                              Glenwood MD 21738
                  email:      mundy@tis.com
                  phone:      301-854-6889

                  Co-editor:  Bert Wijnen
                              IBM T.J. Watson Research
                  postal:     Schagen 33
                              3461 GL Linschoten
                              Netherlands
                  email:      wijnen@vnet.ibm.com
                  phone:      +31-348-412-498

                  Co-editor   Dave Harrington
                              Cabletron Systems, Inc
                  postal:     Post Office Box 5005
                              MailStop: Durham
                              35 Industrial Way
                              Rochester NH 03867-5005
                  email:      dbh@cabletron.com
                  phone:      603-337-7357
                 "

    DESCRIPTION  "The management information definitions for the
                  SNMPng Local Processing Model.
                 "



Wijnen/Harrington         Expires September 1977               [Page 12]


Draft          Local Processing Model (LPM) for SNMPng        March 1997


    ::= { snmpModules xx }

-- Administrative assigments *****************************************

snmpNgLpMIBObjects      OBJECT IDENTIFIER ::= { snmpNgLpMIB 1 }
snmpNgLpMIBConformance  OBJECT IDENTIFIER ::= { snmpNgLpMIB 2 }

-- Information about Local Contexts **********************************

-- Editor's notes:
--        We're still discussing if the contextTable is needed at all
--        See Edotor's notes in section 3.1 under item 4).
-- End Editor's notes.

snmpNgLpContextTable OBJECT-TYPE
    SYNTAX       SEQUENCE OF SnmpNgLpContextEntry
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "The table of locally available contexts.

                 This table is read-only meaning that SNMPng entities
                 in a manager role cannot configure contexts.

                 Instead the table is meant to provide input to SNMPng
                 entities in a manager role sich that they can
                 properly configure the snmpNgLpAcTable to control
                 access to all contexts in an SNMPng entity operating
                 in an agent role.
                "
    ::= { snmpNgLpMIBObjects 1 }

snmpNgLpContextEntry OBJECT-TYPE
    SYNTAX       SnmpNgLpContextEntry
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "Information about a particular context."
    INDEX        { IMPLIED snmpNgLpContextName }
    ::= { snmpNgLpContextTable 1 }

SnmpNgLpContextEntry ::= SEQUENCE
    {
        snmpNgLpContextName        SnmpNgContextName,
        snmpNgLpContextStatus      RowStatus
    }

snmpNgLpContextName OBJECT-TYPE
    SYNTAX       SnmpNgContextName
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "A textual name uniquely identifying a particular
                 context on a particular agent.



Wijnen/Harrington         Expires September 1977               [Page 13]


Draft          Local Processing Model (LPM) for SNMPng        March 1997


                "
    ::= { snmpNgLpContextEntry 1 }

snmpNgLpContextStatus OBJECT-TYPE
    SYNTAX       RowStatus
    MAX-ACCESS   read-only
    STATUS       current
    DESCRIPTION "The status of this conceptual row in the context
                 table.
                "
    ::= { snmpNgLpContextEntry 2 }


-- Information about Access Rights ***********************************

snmpNgLpAcTable OBJECT-TYPE
    SYNTAX      SEQUENCE OF SnmpNgLpAcEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION "The table of group access rights configured in the
                 local configuration datastore (LCD).
                "
    ::= { snmpNgLpMIBObjects 2 }

snmpNgLpAcEntry OBJECT-TYPE
    SYNTAX      SnmpNgLpAcEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION "An access right configured in the local configuration
                 datastore (LCD) authorizing access to a SNMPng
                 context.
                "
    INDEX       { snmpNgLpAcContextName,
                  snmpNgLpAcGroupName,
                  snmpNgLpAcQoS
                }
    ::= { snmpNgLpAcTable 1 }

SnmpNgLpAcEntry ::= SEQUENCE
    {
        snmpNgLpAcContextName      SnmpNgContextName,
        snmpNgLpAcGroupName        SnmpNgGroupName,
        snmpNgLpAcPrivileges       INTEGER,
        snmpNgLpAcReadViewIndex    INTEGER,
        snmpNgLpAcWriteViewIndex   INTEGER,
        snmpNgLpAcStorageType      StorageType,
        snmpNgLpAcStatus           RowStatus
    }

snmpNgLpAcContextName OBJECT-TYPE
    SYNTAX      ContextName



Wijnen/Harrington         Expires September 1977               [Page 14]


Draft          Local Processing Model (LPM) for SNMPng        March 1997


    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION "The context name which identifies an SNMPng context
                 to which this conceptual row grants access rights.
                "
    ::= { snmpNgLpAcEntry 1 }

snmpNgLpAcGroupName OBJECT-TYPE
    SYNTAX      GroupName
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION "The group name which identifies an SNMPng group
                 to which this conceptual row grants access rights.
                "
    ::= { snmpNgLpAcEntry 1 }

snmpNgLpAcQoS OBJECT-TYPE
    SYNTAX      QoS
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION "The minimum level of security required of messages
                 sent on behalf of an entity belonging to the group
                 in order to gain the access rights allowed by this
                 conceptual row.
                "
    ::= { snmpNgLpAcEntry 2 }

snmpNgLpAcPrivileges OBJECT-TYPE
    SYNTAX      BITS { get(0), getNext(1), getBulk(2),
                       set(3), inform(4), snmpv2Trap(5) }
-- Editor's notes:
--          I think we should remove inform... it is not handled in
--          the LP-M. Inform is application to application.
--          I also have no problem if we were to use SNMPv2*
--          values: nothing(1), readOnly(2), readWrite(3)
--
--          There is also the suggestion to do away with this column
--          all together because the Privileges can be detrmined
--          based on the readView or writeView being non-zero.
-- End Editor's notes.

    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION "The access privileges authorized by this conceptual
                 row.  Access privileges specify whether received
                 retrieval and modification requests are permitted
                 to be processed, and whether notifications are
                 permitted to be transmitted.
                 A type of request is authorized if and only if the
                 corresponding enumerated bit is set.
                "



Wijnen/Harrington         Expires September 1977               [Page 15]


Draft          Local Processing Model (LPM) for SNMPng        March 1997


    DEFVAL      { { get, getNext, getBulk } }
    ::= { snmpNgLpAcEntry 3 }

snmpNgLpAcReadViewIndex OBJECT-TYPE
    SYNTAX      INTEGER (0..2147483647)
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION "The value of an instance of this object identifies
                 the MIB view of the SNMPng context to which this
                 conceptual row authorizes read access.
                 The identified MIB view is that for which
                 snmpNgLpViewIndex has the same value as the
                 instance of this object; if the value is zero or
                 there is no MIB view having this value of
                 snmpNgLpViewIndex, then no access is granted.

                 Otherwise, this object is ignored and can take any
                 value at the Local Processing Module's discretion,
                 e.g., zero.

                 Note that read access includes access via retrieval
                 requests as well as transmission of information
                 via notifications (traps).
                "
    DEFVAL      { 0 }
    ::= { snmpNgLpAcEntry 4 }


snmpNgLpAcWriteViewIndex OBJECT-TYPE
    SYNTAX      INTEGER (0..2147483647)
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION "The value of an instance of this object identifies
                 the MIB view of the SNMPng context to which this
                 conceptual row authorizes write access.
                 The identified MIB view is that for which
                 snmpNgLpViewIndex has the same value as the
                 instance of this object; if the value is zero or
                 there is no MIB view having this value of
                 snmpNgLpViewIndex, then no access is granted.

                 Otherwise, this object is ignored and can take any
                 value at the Local Processing Module's discretion,
                 e.g., zero.
                "
    DEFVAL      { 0 }
    ::= { snmpNgLpAcEntry 5 }

snmpNgLpAcStorageType OBJECT-TYPE
    SYNTAX      StorageType
    MAX-ACCESS  read-create



Wijnen/Harrington         Expires September 1977               [Page 16]


Draft          Local Processing Model (LPM) for SNMPng        March 1997


    STATUS      current
    DESCRIPTION "The storage type for this conceptual row.
                 Conceptual rows having the value 'permanent'
                 need not allow write-access to any columnar
                 objects in the row.
                "
    DEFVAL      { nonVolatile }
    ::= { snmpNgLpAcEntry 6 }

snmpNgLpAcStatus OBJECT-TYPE
    SYNTAX      RowStatus
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION "The status of this conceptual row.

                 For those columnar objects which permit write-access,
                 their value in an existing conceptual row can be
                 changed irrespective of the value of snmpNgLpAcStatus
                 for that row.

-- Editor's notes:
--          I am planning to remove the following based on discussions
--          in Montreal between Shawn, JeffJohnson and ourselves
--          where they claimed we should just allow for stale entries.
--
--               A conceptual row in this table is not qualified for
--               activation until the context and the group it
--               references are active.  Further, a conceptual row in
--               this table is immediately made notInService whenever
--               the status of the context or the group it references
--               is made notInService, and immediately destroyed
--               whenever the context or the group it references is
--               destroyed.
--
--          There is also a suggestion as follows (DaveL):
--               Why not just have a set of snmpNgLpViewStatus to
--               destroy(6) either:
--               - fail with an inconsistent value error if any
--                 corresponding entries exist in the
--                 snmpNgLpSubtreeFamilyTable, or
--               - result also in deletion of all corresponding entries
--                 in the snmpNgLpSubtreeFamilyTable.
-- End Editor's notes
                "
    ::= { snmpNgLpAcEntry 7 }

-- Information about MIB views ***************************************
-- Support for views having instance-level granularity is optional

snmpNgLpViewTable OBJECT-TYPE
    SYNTAX      SEQUENCE OF SnmpNgLpViewEntry



Wijnen/Harrington         Expires September 1977               [Page 17]


Draft          Local Processing Model (LPM) for SNMPng        March 1997


    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION "The table of locally defined MIB views.

                 When an SNMPng entity in the manager role wants to
                 create a new MIB view, then it must first create
                 an entry in the snmpNgLpViewTable, using a
                 non-existing index-value for snmpNgLpViewIndex.
                 If the creation of such an entry is successfull,
                 the SNMPng entity in the manager role can then start
                 creating entries in the snmpNgLpSubtreeFamiliyTable.

                 When deleting MIB views, it is stronly advised that
                 first the related snmpNgLpSubtreeFamilityEntries are
                 deleted from the snmpNgLpSubtreeFamiliyTable and that
                 only upon completion of that deletion process the
                 snmpNgLpViewEntry is deleted from the
                 snmpNgLpViewTable.

                 Following these procedures there should be no
                 collisions when multiple managers try to update
                 the MIB views at an SNMPng entity in an agent role.
                "
    ::= { snmpNgLpMIBObjects 3 }

snmpNgLpViewEntry OBJECT-TYPE
    SYNTAX      SnmpNgLpViewEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION "Information on a particular local MIB view."
    INDEX       { snmpNgLpViewIndex }
    ::= { snmpNgLpViewTable 1 }

SnmpNgLpViewEntry ::= SEQUENCE
    {
        snmpNgLpViewIndex        INTEGER,
        snmpNgLpViewName         OCTET STRING,
        snmpNgLpViewStorageType  StorageType,
        snmpNgLpViewStatus       RowStatus
    }

snmpNgLpViewIndex OBJECT-TYPE
    SYNTAX      INTEGER (1..2147483647)
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION "An arbitrary unique value for each MIB view.
                 Once assigned, the value for each MIB view must
                 remain constant for as long as that view is defined,
                 even across re-initializations of the entity's
                 network management system.




Wijnen/Harrington         Expires September 1977               [Page 18]


Draft          Local Processing Model (LPM) for SNMPng        March 1997


-- Editor's notes:
--          I am not sure I understand why this should stay the
--          same. As long as the agent ensures that the mapping
--          between the acTable's use of viewIndex and the indices
--          in this viewTable are in sync, then it should be OK.
--          A manager who wants to add entries to the acTable better
--          checks the views before it actually changes the acTable.
-- End Editor's notes.

                 Thus, the value for a nonVolatile, permanent, or
                 readOnly (see snmpNgLpViewStorageType) MIB view must
                 either be stored as part of the system's non-volatile
                 configuration information, or be able to be
                 re-generated after each re-initialization.

                 The specific value is meaningful only within a given
                 SNMPng entity, i.e., it is not meaningful to any
                 other SNMPng entity except to uniquely identify the
                 view within the set of all views known to this
                 SNMPng entity.
                "
    ::= { snmpNgLpViewEntry 1 }

snmpNgLpViewName OBJECT-TYPE
    SYNTAX      OCTET STRING (SIZE(0..32))
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION "An arbitrary viewName that may help humans recognize
                 the various MIB views.
                "
    DEFVAL      { "" }
    ::= { snmpNgLpViewEntry 2 }


snmpNgLpViewStorageType OBJECT-TYPE
    SYNTAX      StorageType
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION "The storage type for this conceptual row.
                 Conceptual rows having the value 'permanent' need
                 not allow write-access to any columnar objects in
                 the row.
                "
    DEFVAL      { nonVolatile }
    ::= { snmpNgLpViewEntry 3 }

snmpNgLpViewStatus OBJECT-TYPE
    SYNTAX      RowStatus
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION "The status of this conceptual row."



Wijnen/Harrington         Expires September 1977               [Page 19]


Draft          Local Processing Model (LPM) for SNMPng        March 1997


    ::= { snmpNgLpViewEntry 4 }

-- Subtree families of MIB views *************************************

snmpNgLpSubtreeFamilyTable OBJECT-TYPE
    SYNTAX      SEQUENCE OF SnmpNgLpSubtreeFamilyEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION "Locally held information about families of subtrees
                 within MIB views.

                 Each MIB view is defined by two collections of view
                 subtrees: the included view subtrees, and the
                 excluded view subtrees.
                 Every such subtree, both included and excluded,
                 is defined in this table.

                 To determine if a particular object instance is in
                 a particular MIB view, compare the object instance's
                 OBJECT IDENTIFIER with each of the MIB view's active
                 entries in this table.  If none match, then the
                 object instance is not in the MIB view.  If one or
                 more match, then the object instance is included in,
                 or excluded from, the MIB view according to the
                 value of snmpNgLpSubtreeFamilyType in the entry
                 whose value of snmpNgLpSubtreeFamilySubtree has the
                 most sub-identifiers.  If multiple entries match
                 and have the same number of sub-identifiers, then
                 the lexicographically greatest instance of
                 snmpNgLpSubtreeFamilyType determines the inclusion
                 or exclusion.

                 An object instance's OBJECT IDENTIFIER X matches an
                 active entry in this table when the number of
                 sub-identifiers in X is at least as many as in the
                 value of snmpNgLpSubtreeFamilySubtree for the entry,
                 and each sub-identifier in the value of
                 snmpNgLpSubtreeFamilySubtree matches its
                 corresponding sub-identifier in X.
                 Two sub-identifiers match either if the
                 corresponding bit of snmpNgLpSubtreeFamilyMask is
                 zero (the 'wild card' value), or if they are equal.

                 A 'family' of view subtrees is the set of subtrees
                 defined by a particular combination of values of
                 snmpNgLpSubtreeFamilySubtree and
                 snmpNgLpSubtreeFamilyMask.
                 In the case where no 'wild card' is defined in
                 snmpNgLpSubtreeFamilyMask, the family of view
                 subtrees reduces to a single view subtree.




Wijnen/Harrington         Expires September 1977               [Page 20]


Draft          Local Processing Model (LPM) for SNMPng        March 1997


                 When an SNMPng entity in the manager role wants to
                 create a new MIB view, then it must first create
                 an entry in the snmpNgLpViewTable, using a
                 non-existing index-value for snmpNgLpViewIndex.
                 If the creation of such an entry is successfull,
                 the SNMPng entity in the manager role can then start
                 creating entries in the snmpNgLpSubtreeFamiliyTable.

                 When deleting MIB views, it is stronly advised that
                 first the related snmpNgLpSubtreeFamilityEntries are
                 deleted from the snmpNgLpSubtreeFamiliyTable and that
                 only upon completion of that deletion process the
                 snmpNgLpViewEntry is deleted from the
                 snmpNgLpViewTable.

                 Following these procedures there should be no
                 collisions when multiple managers try to update
                 the MIB views at an SNMPng entity in an agent role.

                "
    ::= { snmpNgLpMIBObjects 4 }

snmpNgLpSubtreeFamilyEntry OBJECT-TYPE
    SYNTAX      SnmpNgLpSubtreeFamilyEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION "Information on a particular family of view subtrees
                 included in or excluded from a particular SNMPng
                 context's MIB view.  The MIB view must exist
                 (i.e., be represented by a conceptual row in the
                 snmpNgLpViewTable) before any subtree families can
                 be defined for it.

                 Implementations must not restrict the number of
                 families of view subtrees for a given MIB view,
                 except as dictated by resource constraints on the
                 overall number of entries in the
                 snmpNgLpSubtreeFamilyTable.

                 The value of snmpNgLpViewIndex in this INDEX clause
                 of this table identifies the MIB view in which this
                 subtree family exists.

                 A MIB view for which there are no conceptual rows
                 in this table is the empty set of view subtrees.
                "
    INDEX       { snmpNgLpViewIndex,
                  IMPLIED snmpNgLpSubtreeFamilySubtree
                }
    ::= { snmpNgLpSubtreeFamilyTable 1 }




Wijnen/Harrington         Expires September 1977               [Page 21]


Draft          Local Processing Model (LPM) for SNMPng        March 1997


SnmpNgLpSubtreeFamilyEntry ::= SEQUENCE
    {
        snmpNgLpSubtreeFamilySubtree      OBJECT IDENTIFIER,
        snmpNgLpSubtreeFamilyMask         OCTET STRING,
        snmpNgLpSubtreeFamilyType         INTEGER,
        snmpNgLpSubtreeFamilyStorageType  StorageType,
        snmpNgLpSubtreeFamilyStatus       RowStatus
    }

snmpNgLpSubtreeFamilySubtree OBJECT-TYPE
    SYNTAX      OBJECT IDENTIFIER
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION "The MIB subtree which when combined with the
                 corresponding instance of snmpNgLpSubtreeFamilyMask
                 defines a family of view subtrees.
                "
    ::= { snmpNgLpSubtreeFamilyEntry 1 }

snmpNgLpSubtreeFamilyMask OBJECT-TYPE
    SYNTAX      OCTET STRING (SIZE (0..16))
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION "The bit mask which,
                 in combination with the corresponding instance of
                 snmpNgLpSubtreeFamilySubtree, defines a family of
                 view subtrees.

                 Each bit of this bit mask corresponds to a
                 sub-identifier of snmpNgLpSubtreeFamilySubtree,
                 with the most significant bit of the i-th octet
                 of this octet string value (extended if necessary,
                 see below) corresponding to the (8*i - 7)-th
                 sub-identifier, and the least significant bit of
                 the i-th octet of this octet string corresponding
                 to the (8*i)-th sub-identifier, where i is in the
                 range 1 through 16.

                 Each bit of this bit mask specifies whether or not
                 the corresponding sub-identifiers must match when
                 determining if an OBJECT IDENTIFIER is in this
                 family of view subtrees; a '1' indicates that an
                 exact match must occur; a '0' indicates 'wild card',
                 i.e., any sub-identifier value matches.

                 Thus, the OBJECT IDENTIFIER X of an object instance
                 is contained in a family of view subtrees if, for
                 each sub-identifier of the value of
                 snmpNgLpSubtreeFamilySubtree, either:

                   the i-th bit of snmpNgLpSubtreeFamilyMask is 0, or



Wijnen/Harrington         Expires September 1977               [Page 22]


Draft          Local Processing Model (LPM) for SNMPng        March 1997



                   the i-th sub-identifier of X is equal to the
                   i-th sub-identifier of the value of
                   snmpNgLpSubtreeFamilySubtree.

                 If the value of this bit mask is M bits long
                 and there are more than M sub-identifiers in
                 the corresponding instance of
                 snmpNgLpSubtreeFamilySubtree, then the bit mask
                 is extended with 1's to be the required length.

                 Note that when the value of this object is the
                 zero-length string, this extension rule results in
                 a mask of all-1's being used (i.e., no 'wild card'),
                 and the family of view subtrees is the one view
                 subtree uniquely identified by the corresponding
                 instance of snmpNgLpSubtreeFamilySubtree.
                "
    DEFVAL      { ''H }
    ::= { snmpNgLpSubtreeFamilyEntry 2 }

snmpNgLpSubtreeFamilyType OBJECT-TYPE
    SYNTAX      INTEGER  { included(1), excluded(2) }
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION "The indication of whether the corresponding instances
                 of snmpNgLpSubtreeFamilySubtree and
                 snmpNgLpSubtreeFamilyMask define a family of view
                 subtrees which is included in or excluded from the
                 MIB view.
                "
    DEFVAL      { included }
    ::= { snmpNgLpSubtreeFamilyEntry 3 }

snmpNgLpSubtreeFamilyStorageType OBJECT-TYPE
    SYNTAX      StorageType
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION "The storage type for this conceptual row.
                 Conceptual rows having the value 'permanent' need
                 not allow write-access to any columnar objects in
                 the row.

-- Editor's notes:
--         There is the suggestion from DaveL to let these rows
--         inherit the StorageType from the corresponding entries
--         in the viewTable as the default StorageType.
-- End Editor's notes:
                "
    DEFVAL      { nonVolatile }
    ::= { snmpNgLpSubtreeFamilyEntry 4 }



Wijnen/Harrington         Expires September 1977               [Page 23]


Draft          Local Processing Model (LPM) for SNMPng        March 1997



snmpNgLpSubtreeFamilyStatus OBJECT-TYPE
    SYNTAX      RowStatus
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION "The status of this conceptual row.

                 For those columnar objects which permit write-access,
                 their value in an existing conceptual row can be
                 changed irrespective of the value of
                 snmpNgLpSubtreeFamilyStatus for that row.

                 A conceptual row in this table is not qualified for
                 activation until the MIB view it references is active.
                 Further, a conceptual row in this table is
                 immediately made notInService whenever the status of
                 the view it references is made notInService,
                 and immediately destroyed whenever the
                 view it references is destroyed.
                "
    ::= { snmpNgLpSubtreeFamilyEntry 4 }

-- Information about TRAP destinations *******************************

snmpNgLpTrapDestTable OBJECT-TYPE
    SYNTAX      SEQUENCE OF SnmpNgLpTrapDestEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION "The transport addresses to which notifications
                 (traps) are to be sent on behalf of specific
                 SNMPng groups.
                "
    ::= { snmpNgLpMIBObjects 5 }

snmpNgLpTrapDestEntry OBJECT-TYPE
    SYNTAX      SnmpNgLpTrapDestEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION "A transport address to which notifications (traps)
                 are to be sent on behalf of a specific SNMPng group
                "
    INDEX       { snmpNgLpTrapDestTDomain,
                  IMPLIED snmpNgLpTrapDestTAddress
                }
    ::= { snmpNgLpTrapDestTable 1 }

SnmpNgLpTrapDestEntry ::= SEQUENCE
    {
        snmpNgLpTrapDestTDomain          TDomain,
        snmpNgLpTrapDestTAddress         TAddress,
        snmpNgLpTrapDestQos              SnmpNgQos,



Wijnen/Harrington         Expires September 1977               [Page 24]


Draft          Local Processing Model (LPM) for SNMPng        March 1997


        snmpNgLpTrapDestGroupName        SnmpGroupName,
        snmpNgLpTrapDestSecModel         SnmpNgSecurityModel,
        snmpNgLpTrapDestStorageType      StorageType,
        snmpNgLpTrapDestStatus           RowStatus
    }

snmpNgLpTrapDestTDomain OBJECT-TYPE
    SYNTAX      TDomain
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION "Indicates the kind of transport service for this
                 transport address.
                "
    DEFAULT     { snmpUDPDomain }
    ::= { snmpNgLpTrapDestAddressEntry 1 }


snmpNgLpTrapDestTAddress OBJECT-TYPE
    SYNTAX      TAddress
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION "The transport service address.

                 The address is formatted according to the
                 corresponding value of snmpNgLpTrapDestTDomain.

                 For example, for the transport domain corresponding
                 to the snmpUDPDomain, transportAddress is formatted
                 as a 4-octet IP Address concatenated with a 2-octet
                 UDP port number.

                 See [RFC1906] for more information on transport
                 domains and how their corresponding addresses are
                 formatted.
                "
    ::= { snmpNgLpTrapDestEntry 2 }

snmpNgLpTrapDestQos    OBJECT-TYPE
    SYNTAX      SnmpNgQos
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION "The Qos to use when sending a notification (trap)
                 to this destination.
                "
    DEFVAL      { 2 }   -- auth
    ::= { snmpNgLpTrapDestEntry 4 }

snmpNgLpTrapDestGroupName OBJECT-TYPE
    SYNTAX      SnmpNgGroupName
    MAX-ACCESS  read-create
    STATUS      current



Wijnen/Harrington         Expires September 1977               [Page 25]


Draft          Local Processing Model (LPM) for SNMPng        March 1997


    DESCRIPTION "The group name to use when applying access control
                 to the management information contained in the
                 notification (trap) to be sent.
                "
    ::= { snmpNgLpTrapDestEntry 5 }

snmpNgLpTrapDestSecModel OBJECT-TYPE
    SYNTAX      SnmpNgSecurityModel
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION "The Security Model to use when applying security
                 measures to the SNMP message before sending it
                 to this destination.
                "
    ::= { snmpNgLpTrapDestEntry 6 }

snmpNgLpTrapDestStorageType OBJECT-TYPE
    SYNTAX      StorageType
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION "The storage type for this conceptual row.
                 Conceptual rows having the value 'permanent' need
                 not allow write-access to any columnar objects in
                 the row.
                "
    DEFVAL      { nonVolatile }
    ::= { snmpNgLpTrapDestEntry 7 }

snmpNgLpTrapDestStatus OBJECT-TYPE
    SYNTAX      RowStatus
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION "The status of this conceptual row."
    ::= { snmpNgLpTrapDestEntry 8 }

-- Conformance information *******************************************
snmpNgLpMIBCompliances
               OBJECT IDENTIFIER ::= { snmpNgLpMIBConformance 1 }
snmpNgLpMIBGroups
               OBJECT IDENTIFIER ::= { snmpNgLpMIBConformance 2 }

-- Compliance statements *********************************************

snmpNgLpMIBCompliance MODULE-COMPLIANCE
    STATUS  current
    DESCRIPTION
           "The compliance statement for SNMPng entities which
            implement the SNMPng LP-M remote configuration MIB.
           "
    MODULE -- this module
        MANDATORY-GROUPS { snmpNgLpBasicGroup }



Wijnen/Harrington         Expires September 1977               [Page 26]


Draft          Local Processing Model (LPM) for SNMPng        March 1997



        OBJECT        snmpNgLpViewStorageType
        MIN-ACCESS    read-only
        DESCRIPTION  "Write access is not required."

        OBJECT        snmpNgLpViewStatus
        MIN-ACCESS    read-only
        DESCRIPTION  "Create access to the snmpNgLpViewTable
                      is not required.
                     "

        OBJECT        snmpNgLpSubtreeFamilyMask
        WRITE-SYNTAX  OCTET STRING (SIZE (0))
        MIN-ACCESS    read-only
        DESCRIPTION  "Support for configuration via SNMPng of
                      subtree families defined using wild-cards
                      is not required.
                     "

        OBJECT        snmpNgLpSubtreeFamilyStorageType
        MIN-ACCESS    read-only
        DESCRIPTION  "Write access is not required."

        OBJECT        snmpNgLpSubtreeFamilyStatus
        MIN-ACCESS    read-only
        DESCRIPTION  "Create access to the snmpNgLpSubtreeFamilyTable
                      is not required.
                     "
    ::= { snmpNgLpMIBCompliances 1 }

-- Units of conformance **********************************************

snmpNgLpBasicGroup OBJECT-GROUP
    OBJECTS { snmpNgLpContextStatus,
              snmpNgLpAcPrivileges,
              snmpNgLpAcReadViewIndex,
              snmpNgLpAcWriteViewIndex,
              snmpNgLpAcStorageType,
              snmpNgLpAcStatus,
              snmpNgLpViewStorageType,
              snmpNgLpViewStatus,
              snmpNgLpSubtreeFamilyMask,
              snmpNgLpSubtreeFamilyType,
              snmpNgLpSubtreeFamilyStorageType,  -- length 32 !!
              snmpNgLpSubtreeFamilyStatus,
              snmpNgLpTrapDestQos,
              snmpNgLpTrapDestGroupName,
              snmpNgLpTrapDestSecModel,
              snmpNgLpTrapDestStorageType,
              snmpNgLpTrapDestStatus
            }



Wijnen/Harrington         Expires September 1977               [Page 27]


Draft          Local Processing Model (LPM) for SNMPng        March 1997


    STATUS  current
    DESCRIPTION
           "A collection of objects providing for remote
            configuration of an SNMPng entity which implements
            the SNMPng Local Processing Model (LP-M).
           "
    ::= { snmpNgLpMIBGroups 1 }

END













































Wijnen/Harrington         Expires September 1977               [Page 28]


Draft          Local Processing Model (LPM) for SNMPng        March 1997


5.  Security Considerations

5.1  Recommended Practices

This document is part of the SNMPng Architectural Model. The
Local Processing Model (LP-M) described in this document controls
access rights to management information based on:

   - contextName, representing a set of management information
     at the managed system where the Local Processing Implenetation
     (LP-I) is running.
   - groupName, representing a group or set of zero, one or more
     security entities. These security entities are mapped into
     one or more groups in the SNMPng Securty Framework Model
     (SF-M).
   - Qos used for the transmission of a SNMP message.

When the LP-I is called for processing a Scoped-PDU, it is assumed
that the Message Processing and Control Implementation (MPC-I)
has ensured the authentication and privacy aspects as specified
by the Quality of service (Qos) that is being passed.

5.2  Defining Groups

GroupNames are used to give access to a group of zero, one or more
security entities. Within the LPM, a Groupname is considered to
exist if that groupName is used (as an index) in a row in the
snmpNgLpAcTable.
By mapping a security entity into a group, a SF-M for SNMPng can
add/delete entities to a group.

5.3  Conformance

Conformance rules are described in the Architectural Model for SNMPng.




















Wijnen/Harrington         Expires September 1977               [Page 29]


Draft          Local Processing Model (LPM) for SNMPng        March 1997


6.  Editor's Addresses

   Co-editor:  Bert Wijnen
               IBM T.J. Watson Research
   postal:     Schagen 33
               3461 GL Linschoten
               Netherlands
   email:      wijnen@vnet.ibm.com
   phone:      +31-348-412-498

   Co-editor   Dave Harrington
               Cabletron Systems, Inc
   postal:     Post Office Box 5005
               MailStop: Durham
               35 Industrial Way
               Rochester NH 03867-5005
   email:      dbh@cabletron.com
   phone:      603-337-7357


7.  Acknowledgements

This document describes the work of the SNMP Security and
Administrative Framework Evolution team, comprised of

    David Harrington (Cabletron Systems Inc.)
    Jeff Johnson (Cisco)
    David Levi (SNMP Research Inc.)
    John Linn (Openvision)
    Russ Mundy (Trusted Information Systems) chair
    Shawn Routhier (Epilogue)
    Glenn Waters (Nortel)
    Bert Wijnen (IBM T.J. Watson Research)





















Wijnen/Harrington         Expires September 1977               [Page 30]


Draft          Local Processing Model (LPM) for SNMPng        March 1997


8.  References

[RFC1902] The SNMPv2 Working Group, Case, J., McCloghrie, K.,
     Rose, M., and S., Waldbusser, "Structure of Management
     Information for Version  2 of the Simple Network Management
     Protocol (SNMPv2)", RFC 1905, January 1996.

[RFC1905] The SNMPv2 Working Group, Case, J., McCloghrie, K.,
     Rose, M., and S., Waldbusser, "Protocol Operations for
     Version 2 of the Simple Network Management Protocol (SNMPv2)",
     RFC 1905, January 1996.

[RFC1906] The SNMPv2 Working Group, Case, J., McCloghrie, K.,
     Rose, M., and S. Waldbusser, "Transport Mappings for
     Version 2 of the Simple Network Management Protocol (SNMPv2)",
     RFC 1906, January 1996.

[RFC1907] The SNMPv2 Working Group, Case, J., McCloghrie, K.,
     Rose, M., and S. Waldbusser, "Management Information Base for
     Version 2 of the Simple Network Management Protocol (SNMPv2)",
     RFC 1907 January 1996.

[RFC1908] The SNMPv2 Working Group, Case, J., McCloghrie, K.,
     Rose, M., and S. Waldbusser, "Coexistence between Version 1
     and Version 2 of the Internet-standard Network Management
     Framework", RFC 1908, January 1996.

[SNMPng-ARCH] The SNMPng Working Group, Harrington, D., Wijnen, B.,
     "Architectural Model for the Next Generation Simple Network
     Managememt Protocol (SNMPng)", draft-ietf-snmpv3-arch-00.txt,
     March 1997.

[SNMPng-LPM] The SNMPng Working Group, Wijnen, B., Harrington, D.,
     "Local Processing Model for the Next Generation Simple Network
     Management Protocol (SNMPng)", draft-ietf-snmpv3-lpm-00.txt,
     March 1997.

[SNMPng-USEC] To be written
              The SNMPng Working Group, Editors...Names,
     "The User-Based Security Model for the Next Generation Simple
     Network Managememt Protocol (SNMPng)",
     draft-ietf-snmpv3-usec-00.txt, April 1997.












Wijnen/Harrington         Expires September 1977               [Page 31]


Draft          Local Processing Model (LPM) for SNMPng        March 1997


APPENDIX A - Installation

Editor's notes:
         portions of the following still need to be moved to
         the appropriate documents. I am just listing them here
         so that we have one place where we can see what is
         needed.
End Editor's notes.

A.1.   Agent Installation Parameters

During installation, an SNMPng entity acting in an agent role is
configured with several parameters.  These include:

(1) a security posture (todo in SNMPng-MPC)

    The choice of security posture determines the extent of the view
    configured for unauthenticated access.  One of three possible
    choices is selected:

          minimum-secure,
          semi-secure, or
          very-secure.

(2) one or more transport service addresses (todo in SNMPng-MPC)

    These parameters may be specified explicitly, or they may be
    specified implicitly as the same set of network-layer addresses
    configured for other uses by the device together with the well-
    known transport-layer "port" information for the appropriate
    transport domain [RFC1906].  The agent listens on each of these
    transport service addresses for messages.

(3) one or more secrets (todo in SNMPng-USEC)

    These are the authentication/privacy secrets for the first user
    to be configured.

    One way to accomplish this is to have the installer enter a
    "password" for each required secret. The password is then
    algorithmically converted into the required secret by:

    - forming a string of length 1,048,576 octets by repeating the
      value of the password as often as necessary, truncating
      accordingly, and using the resulting string as the input to
      the MD5 algorithm.  The resulting digest, termed "digest1",
      is used in the next step.

    - a second string of length 44 octets is formed by concatenating
      digest1, the SNMPng engine's snmpNgEngineID value, and digest1.
      This string is used as input to the MD5 algorithm.



Wijnen/Harrington         Expires September 1977               [Page 32]


Draft          Local Processing Model (LPM) for SNMPng        March 1997


      The resulting digest is the required secret (see Appendix A.2).

    With these configured parameters, the SNMPng entity instantiates
    the following snmpNgUsecUserEntry,

                                no privacy support  privacy support
                                ------------------  ---------------
      snmpNgUsecEngineID        localEngineID       localEngineID
      snmpNgUsecUserName        "public"            "public"
      snmpNgUsecGroupName       "public"            "public"
      snmpNgUsecAuthProto       snmpMD5Protocol     snmpMD5Protocol
      snmpNgUsecPrivProto       none                snmpDESProtocol
      snmpNgUserSecurityCookie  ""                  ""


(4) The SNMPng LP-M the SNMPng entity in an agent role must
    instantiate the following views and access rights.  This
    configuration information should be readOnly (persistent).

    -  One context with its <contextName> as the empty-string "".
       This represents the default context.

    -  One view (the <all> view) for authenticated access:

       - the <all> MIB view is the following subtree:
              "internet"        [RFC1902]

    -  A second view (the <restricted> view) for unauthenticated
       access.  This view is configured according to the selected
       security posture:

       -  For the "very-secure" posture:

          the <restricted> MIB view is the union of these subtrees:
              "snmp"            [RFC1907]
              "snmpNgStats"     [SNMPng-ARCH]
              "snmpNgUsecStats" [SNMPng-USEC]

       -  For the "semi-secure" posture:

          the <restricted> MIB view is the union of these subtrees:
              "snmp"            [RFC1907]
              "snmpNgStats"     [SNMPng-ARCH]
              "snmpNgUsecStats" [SNMPng-USEC]
              "system"          [RFC1902]

       -  For the "minimum-secure" posture:

          the <restricted> MIB view is the following subtree.
              "internet"        [RFC1902]




Wijnen/Harrington         Expires September 1977               [Page 33]


Draft          Local Processing Model (LPM) for SNMPng        March 1997


    -  Access rights to allow:

       - read-only access for Qos "noAuth" on behalf of security
         entities that belong to the group "public" to the
         <restricted> MIB view in the context with contextName "".

       - read-write access for Qos "auth" on behalf of security
         entities that belong to the group "public" to the
         <all> MIB view in the context with contextName "".

       - if privacy is supported,
         read-write access for Qos "auth" on behalf of security
         entities that belong to the group "public" to the
         <all> MIB view in the context with contextName "".








































Wijnen/Harrington         Expires September 1977               [Page 34]


Draft          Local Processing Model (LPM) for SNMPng        March 1997


A.2.   Password to Key Algorithm

Editor's Notes:
    The following goes into SNMPng-USEC doc.
End Editor's notes.

The following code fragment demonstrates the password to key
algorithm which can be used when mapping a password to an
authentication or privacy key. The calls to MD5 are as
documented in RFC1321 [RFC1321]

void password_to_key(
   u_char *password,    /* IN */
   u_int   passwordlen, /* IN */
   u_char *agentID,     /* IN  - ptr to 12 octet long snmpEngineID  */
   u_char *key)         /* OUT - caller's pointer to 16-byte buffer */
{
   MD5_CTX     MD;
   u_char     *cp, password_buf[64];
   u_long      password_index = 0;
   u_long      count = 0, i;

   MD5Init (&MD);   /* initialize MD5 */

   /**********************************************/
   /* Use while loop until we've done 1 Megabyte */
   /**********************************************/
   while (count < 1048576) {
      cp = password_buf;
      for (i = 0; i < 64; i++) {
          /*************************************************/
          /* Take the next byte of the password, wrapping  */
          /* to the beginning of the password as necessary.*/
          /*************************************************/
          *cp++ = password[password_index++ % passwordlen];
      }
      MDupdate (&MD, password_buf, 64);
      count += 64;
   }
   MD5Final (key, &MD);          /* tell MD5 we're done */

   /*****************************************************/
   /* Now localize the key with the agentID and pass    */
   /* through MD5 to produce final key                  */
   /*****************************************************/
   memcpy(password_buf, key, 16);
   memcpy(password_buf+16, agentID, 12);
   memcpy(password_buf+28, key, 16);

   MD5Init(&MD);
   MDupdate(&MD, password_buf, 44);



Wijnen/Harrington         Expires September 1977               [Page 35]


Draft          Local Processing Model (LPM) for SNMPng        March 1997


   MD5Final(key, &MD);

   return;
}


















































Wijnen/Harrington         Expires September 1977               [Page 36]


Draft          Local Processing Model (LPM) for SNMPng        March 1997


Table of Contents

0.  Change Log                                                         2
1.  Introduction                                                       3
1.1  Terminology                                                       3
1.2  Local Processing                                                  3
1.3  Local Configuration Datastore                                     4
2.  Elements of the Model                                              5
2.1  SNMPng Group                                                      5
2.2  SNMPng Quality of Service (Qos)                                   5
2.3  Contexts                                                          5
2.4  SNMPng Scoped-PDU                                                 6
2.5  Access Policy                                                     7
2.6.  Error Reporting                                                  7
3.  Elements of Procedure                                              8
3.1  Processing a Received Scoped-PDU                                  8
3.2  Generating a Notification                                        10
4.  Definitions                                                       12
5.  Security Considerations                                           29
5.1  Recommended Practices                                            29
5.2  Defining Groups                                                  29
5.3  Conformance                                                      29
6.  Editor's Addresses                                                30
7.  Acknowledgements                                                  30
8.  References                                                        31
A.1.   Agent Installation Parameters                                  32
A.2.   Password to Key Algorithm                                      35





























Wijnen/Harrington         Expires September 1977               [Page 37]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/