Subject: Minutes of Chicago IETF (42) disman meeting

From: Dale Francisco <[email-masked]>
Date: Tue, 15 Sep 1998 15:04:32 -0700 (PDT)

Meeting of the Distributed Management (disman) working group
at IETF-42 Chicago (Thu 8/27/98 0900-1130)

Reported by Dale Francisco ([email-masked])

Randy Presuhn, Chair ([email-masked])

For more information on the disman wg, please see:
    http://www.ietf.org/html.charters/disman-charter.html

Randy began the meeting with a brief review of the
agenda:
        Administrative matters      10 min. 
        Status of current work      20 min.
        Technical presentations      1 hr.
        Relations with other wgs,    
        charter discussion           1 hr.
        Wrapup                       5 min.

Status of Current work
======================
    The script MIB and schedule MIB are with the IESG.
    Bob Stewart did new drafts of Notification, Event,
    and Expression MIBs--please submit comments on these
    items.  The question arose as to the appropriate time
    for wg last call on these MIBs.  A show of hands revealed
    that only 5 people have read the documents so far.

    Bob Stewart mentioned that he had received a few private
    communications on Notification logging, in particular a
    suggestion that it might be useful to have separate logs
    per manager (easier filtering, less computationally expensive
    than determining access privileges on a per-entry basis).
    Randy stressed the need to be clear on the security implications
    of logging.  A couple of people mentioned the advantages
    for scalability and disconnected operation that notification
    logging would provide.

    It was decided that the deadline for comments on these
    three MIBs would be six weeks after the meeting, and
    Bob committed to turning the documents in no more than
    two weeks after that time.  The goal would be last call
    at the end of October.

    Steve Waldbusser discussed the status of the Framework document.
    At this point, it's mostly minor edits and fixes of typos.  Steve
    urged as many people as possible to read it.  Six people were
    willing to read it within the next month, and 12 within the
    next six weeks.  It was decided that mid October would be the
    final comment date, with end of October for final revised
    docs.

Technical Presentations
=======================

1)  Remote Ping and Traceroute through a MIB
    Ken White, IBM ([email-masked])

    See draft-ietf-disman-remops-mib-01.txt.

    There are many enterprise solutions for remote ping, but
    not for traceroute.  The intent of this work is to
    provide an interoperable MIB for both ping and
    traceroute remote operation.  The current draft has many
    improvements based on experience and suggestions.  A
    Results table approach was taken to overcome the
    mismatch between the minimal requirement for SNMP
    maximum message size (484 bytes) and potentially larger
    strings from traceroute results.

    Future work includes:
        - Consider traceroute over ip-multicast
        - IPv6 implementation of ping

    The REMOPS-MIB consists of 2 notifications, 5 scalars,
    and 4 tables with 21 objects.  Two tables are used to
    configure the remote operations, and two to store the
    results.  The target address can be a DNS name, IPv4 address,
    or IPv6 address.  Features of the remopsPingTable and the
    remopsTraceRouteTable (application configuration) include:

        - Entries created and deleted via RowStatus
        - remopsPingOperStatus to indicate status of request
        - remopsPingOwnerIndex to allow v3 VACM

    Two scalars are used for controlling resource use by
    the REMOPS-MIB instrumentation.  MaxConcurrentRequests
    limits the number of concurrent actions, and
    PurgeTime (the amount of time a result remains in
    the ResultTable after the associated request completes)
    can be used to keep the ResultTable within size constraints.

    During the question and comment period, Bob Stewart
    suggested that the best way to think of this was as
    an application that happens to have a MIB controlling
    it.

    A question arose as to whether DNS name support
    was really needed.  Some suggested that the DNS
    names of intermediate nodes should be returned
    because that's how traceroute worked, but others
    argued that many embedded systems may not have
    DNS support.  Ken said that 95% of the time DNS
    support wasn't needed, but it was there as an
    option (off by default).

    Finally, there was discussion of the trade-offs between
    a dedicated remote operations MIB and a script MIB
    approach.  Ken felt that the ping and traceroute MIBs
    were (obviously) much simpler to implement and less resource
    intensive, and that they could be used in places
    where there was no script MIB support.

2)  Implementation of SMX
    David Levi ([email-masked])

    David Levi gave a brief discussion and slide presentation
    on SMX (Script MIB Extensibility), a research project of
    Jurgen Schonwalder, who was unable to attend the meeting.
    Please see www.ibr.cs.tu-bs.de/projects/jasmin/ for more
    information.

    Jasmin (JAva Script Mib ImplementatioN)
    Goals:
        - Evaluate the current script MIB proposal by
          implementing and using it.
        - Use the JVM as the primary runtime system.
        - Create an architecture that allows plugging in
          alternate runtime systems.
        - Share implementation experience with the disman wg.

    Internal architecture:
        SMX is the protocol for communication between the runtime
        systems (which are actually executing scripts) and the SNMP Agent.

        SMX protocol details:
            TCP is used between runtime systems and the SNMP agent.
            Messages contain simple ASCII encodings similar to SMTP, HTTP;
            there is an assumption of the existence of a shared file
            system between the SMX peers.

            The SMX peer inside the SNMP agent sends commands to the
            runtime system.  The runtime system responds to commands
            or sends asynchronous messages.

            Enforcement of integrity and security is the responsibility
            of the agent.

            The SMX protocol is simple (a small number of commands) in
            order to make it easy to create new runtime systems.
            The format of messages is defined using the ABNF (RFC 2234).

            There are 6 commands (hello, start, suspend, resume, abort,
            and status) which are sent by the SNMP agent.  There are
            15 reply codes sent by the runtime system (which could be
            Java VM, Tcl, other).  In the current implementation,
            most replies are sent in response from a SNMP subagent
            written in C, based on EMANATE (though it doesn't use the
            data structures generated by the MIB compiler).  Currently,
            it's about 12,000 lines of commented C code.

        Jasmin Java Runtime:
            Based on JDK 1.1.5, the runtime system allows multiple scripts
            with the same runtime security profile to execute.
            
            The system is written in 99% pure Java (with a little C to
            get at a cookie at startup).  The system is available for
            testing on the net, at
                osborne.ibr.cs.tu-bs.de port 161

        Future projects:
            - Implement a Tcl runtime system.
            - Implement some useful real-world management scripts.

3)  Bulk Transfer
    Bob Stewart ([email-masked])

    (no slides)

    The main point of this discussion was to describe
    the Bulk Transfer MIB concept and to present and
    solicit ideas on future work.

    The purpose of the Bulk Transfer MIB is to deal
    with complaints about the slowness of retrieving
    large amounts of data with SNMP, while maintaining
    the underlying data structures and MIBs.  The basic
    idea is that the MIB is used to specify which objects
    (in other MIBs) are of interest, then let the instrumentation
    write the data to a file for quick retrieval.  There are
    different file formats available, including ASCII and
    binary.

    Some of the nice features of the Bulk Transfer file
    format include:
    
        - Unlike GetBulk, tables are squared up
          (there's an indication of NULL for missing values).
          
        - Redundant parts of OIDs are removed to cut file size.

    Since not all systems have file systems, a separate FTP-CLIENT
    MIB was implemented that allows sending the file to a
    particular server instead of storing it locally.
    The concept of an "ephemeral file" (a file that exists only one buffer
    at a time) is the glue between BULK-TRANSFER and FTP-CLIENT.

    Summary: This is a very different way of getting SNMP data,
    particularly appropriate to frequently polled, large tables.

    Bob stated that these MIBs would be available soon at
    a to-be-announced URL.  There was general consensus that
    this sort of application was something that would be
    useful across many working groups.

4)  Framework Document (draft-ietf-disman-framework-02.txt)
    Steve Waldbusser ([email-masked])

    (no slides)

    Steve started by saying that he was mostly here to ask
    questions.  Disman describes 8 to 10 services, one of which
    is the Credential Delegation Service (CDS).  Since there
    hadn't been any discussion of CDS since the last meeting,
    he wanted to discuss issues and go out with marching orders.

    CDS is required when a management station talks to a
    distributed manager which in turn talks to a target
    agent.  The management station uses authentication to
    talk to the distributed manager.  But what does the
    distributed manager use to talk to target agent?
    Without CDS, it could only use credentials stored in the
    distributed manager, with no relation to particular
    management stations.  The problem is there's no mean of
    divvying them up--if available to one "good guy" MS,
    it's available to all (this is spelled out in the
    Framework).  Credentials == keys (identities +
    passwords).  Without CDS, it's all-or-nothing access to
    whatever rights the distributed manager has.  So it only
    works for a secure distributed manager.

    One solution includes a credential store (MIB) within
    the distributed manager.  So, for instance, some rows in the REMOPS MIB
    would have a fragment from the CDS-MIB.

    A practical IETF question: How to add this MIB fragment to
    already-progressed MIBs?
        a) Add CDS to existing MIBs (all MIBs that want to
           use CDS would need to add it--i.e., all 5 disman MIBs)
        b) Define CDS today anyway, and add it to selected MIBs
           when possible.
        c) Separate the current draft into a Framework document
           and a CDS MIB document.

    Randy said that it was unquestionable that disman needed
    CDS; the question was, where to put the MIB definition?
    For that set of MIBs that need it, what is the strategy
    for getting there?  He suggested that the CDS MIB probably
    belongs in the Framework, and that the strategy might be to
    recycle out-the-door MIBs when available, and fix in-progress ones
    now.

    There followed a discussion of the pros and cons of
    separating CDS from the rest of the Framework into a new
    doc, keeping the Framework MIB-free.  Bert Wijnen, area
    director, after hearing from Steve and David Levi that
    the docs could be separated in a week, inclined towards
    separate documents.  The working group agreed.

Relations with other WGs
========================
    Randy said that he hadn't yet had a chance to discuss with
    the AgentX or v3 working groups any disman interoperability
    questions.  But there was a question whether it was possible
    to do a disman implementation in a "pure" AgentX environment;
    the main concern was whether there would be access to the
    isAccessAllowed() ASI.

    The best way to lay out the discussion that followed is
    to attribute it to speakers (paraphrased, not exact
    quotes):

    Randy:        Should we demand support from AgentX?
    Bob Stewart:  Outline the problems, make them clear to AgentX,
                  then let AgentX do what they want.
    Waldbusser:   I'm offended that we need those things--it breaks
                  SNMP as we know it.
    Randy:        A command responder needs access to isAccessAllowed().
    Bob Natale (AgentX chair): Post it to the AgentX list.
    Randy:        What I wanted to get here is that some of the postings
                  on the mailing list have insisted that these are disman
                  requirements.  So, is it the sense of the group that this
                  is a requirement, or that there are just a few members
                  that think we need it?
    Waldbusser:   Up to this point, disman has been just another SNMP
                  application--now we're talking about special privileges.
    Bob Stewart:  We're talking about the benefits of local access to MIB
                  data, not a _requirement_.  isAccessAllowed() is a
                  good example.
    Bob Natale:   The A-Ds say that cooperation is needed among the entity,
                  v3, agentx, and disman working groups.  I propose this
                  consensus: For the purpose of implementing disman MIBs,
                  availability of isAccessAllowed() and knowledge of operation
                  invoker parameters is highly desirable; AgentX may be an
                  appropriate vehicle for accomplishing that; and we want
                  to investigate.
    Bob Stewart:  If we're implementing in AgentX, we absolutely need
                  the capability.
    Randy:        No question...but is AgentX the desired vehicle?
    Jon Saperia:  Is there a need for this in a subagent?
    Randy, Bob:   Yes.
    Bert Wijnen:  But is this really an AgentX issue?
    Randy:        If it's not tied to the AgentX API, it'll get real messy
                  because of synchronization problems.
    Bert:         AgentX wasn't supposed to worry about security issues.

    After this discussion, it was the consensus of the working group
    that Randy should take the action item of posting to the AgentX
    list a clear statement of the problem.

Charter updates
===============
    Target for end of comments: Oct 16, 1998
           for revised drafts:  Oct 30, 1998

    Possible additions to charter:
        Remote Operations MIB--The consensus was that about 8 interested
        people wanted to see it happen, and 2 people would commit
        to help with writing and reviewing the documents.
        So we'll add it to the charter.

        Script MIB extensibility (SMX)--We don't have enough
        understanding yet, so let's not add it.  More investigation
        is needed--defer to next meeting consideration of adding it
        to the charter.

        Bulk Transfer--The consensus was that this was really
        core, not disman, work.  Action item for Bert Wijnen:
        Where should we kickoff discussion of this topic?

Wrapup
======
    We will meet at the next IETF, yes?
    Consensus of working group: Yes!