Subject: RE: [nmrg] upcoming nmrg meeting
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: [email-masked], [email-masked]
Date: Mon, 30 Jun 2003 16:57:29 +0200
List-Id: Network Management Research Group <nmrg.ibr.cs.tu-bs.de>

I plan to attend.
Is it located close to where IETF is being held, or shoudl we
switch hotels as well?

Thanks,
Bert 

Date: Thu, 26 Jun 2003 17:03:38 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [nmrg] meeting notes (colorado springs)
Sender: [email-masked]

--FCuugMFkClbJLl1L
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Attached are the meeting minutes from the Colorado Springs meeting.
Thanks to John Strassner for editing the raw material into these 
minutes.

Please check the minutes and let us know by the end of this months
whether there is something that needs to be changed.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

--FCuugMFkClbJLl1L
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="12thXNMRGXMeetingXMinutes-text.txt"

12th NMRG Meeting Minutes, 22-23 March, 2003
Location: Colorado Springs, Colorado, USA
Host:  Intelliden (John Strassner)
Note-takers: John Strassner, Juergen Schoenwaelder

Attendees:
  * Olivier Festor
  * David Harrington
  * James Hong
  * Torsten Klie
  * Emmanuel Nataf
  * George Pavlou
  * David Perkins
  * Aiko Pras
  * Phil Shafer
  * Juergen Schoenwaelder
  * Frank Strauss
  * John Strassner
  * Bert Wijnen

The meeting was held in accordance with the published agenda, with 
some minor changes and additions. Thus, the revised agenda will be 
used as an outline for the notes. The Agenda is as follows:

Saturday (2003-03-22) (13:00 - 17:00)
  * Welcome
  * Select note takers and minute producers
  * Status reports
  * Recent achievements
  * 11th meeting minutes
  * OID compression paper
  * ITU SG 4 input on SNMP over TCP
  * Latest IETF news (new/closed WGs, rumors and mysteries)
  * SMIng status report (F. Strauss, J. Schoenwaelder)
  * SMI -> XSD translation and gateway (T. Klie, F. Strauss)
  * Plans for dinner

Sunday (2003-03-23) (09:00-12:00, 13:00-17:00)
  * Short summary of the Saturday meeting
  * Bert's input and comment on the latest IETF news
  * SMI -> XSD wrap-up discussion
  * Technical XMLCONF discussion (Phil)
  * Wrap up and action items
  * Plans for dinner

Please note that on Tuesday, at IM03, there is an important 
discussion from 17:00-18:30. It covers the following two topics:
  * IAB research funding document feedback
  * Restructuring and refocus of the NMRG

After a welcome from John (the host) and introductions of the 
participants, the meeting began.

ITEM: Recent Achievements (under Status reports)
  * RFC 3430: Simple Network Management Protocol Over Transmission 
              Control Protocol Transport Mapping.
    This was published December 2002.
  * RFC 3440: On the Difference between Information Models and Data 
              Models.
    This was published January 2003

Both of these documents are available on the website and through the
IETF repository.

Regarding OID compression, Aiko and Juergen were going to collaborate 
and try and produce a paper. No date given for completion.

ITU SG-4 input on SNMP over TCP document went to Bert. A university 
in Asia tried to implement it. Level of detail wasn't very precise, 
so Juergen wrote a response (copied the NMRG list) but hasn't received 
a reply to this yet.

ITEM: Latest IETF news
  * SMIng and EOS working groups will be shut down very soon.
  * SNMP is going into maintenance mode. A working group may be 
    chartered to do this, but it will be given one task at a time and 
    if it fails to complete a task, then the working group will be 
    shut down. The other approach is to have a design team reporting 
    directly to the OPS ADs. It was restated that SNMP is not useful 
    for configuring routers. A couple of operators from the cable and 
    ATM community said that they use SNMP MIBs, at which point Randy 
    narrowed this to routers running IP.
  * PIBs will no longer be allowed on the standards track. In fact, 
    further PIB work is going to be discouraged. However, COPS-PR is
    on the standards track, so if it is to be released, they need to
    prove that people are using COPS-PR with some PIBs.
  * Readable MIBs are still required from WGs where applicable
  * Writable MIBs can be worked on, but are NOT required any longer. 
    Note that there have been different interpretations of statements 
    from various sources observed, making a precise interpretation 
    of this statement impossible; group will ask Bert when he arrives.
  * XML configuration management working group renamed NetConf, and 
    will be started soon. NetConf looks promising - readable MIBs are 
    required, writable MIBs are optional. Some operators agreed to 
    work on the NetConf document. Had gotten feedback that they 
    needed to work on some underlying data model issues.
  * It is desired that operators co-chair OPS area working groups. 
    This is likely to be enforced for the XML configuration 
    management working group.
  * Wes thinks that SNMP fixes/evolution are still needed, even if 
    XML might take over in the future, and in spite of the demise of 
    the EOS and SMing working groups. Wes also thinks that SNMPv3 
    might benefit from a session based security model in order to 
    integrate better with established authentication mechanisms.
  * Since PIBs and MIBs couldn't coexist, how can the data models for 
    SNMP and NetConf coexist? (open question)
  * The following are notes from Dave, who attended the OPS area 
    meeting:
    * AAA stuff: Bernard presented, said that AAA was being used by 
      IEEE, 3GPP, and 3GPP2. 802.11 (wireless) has more of a strained 
      relationship because they weren't sharing information with the 
      IETF; this is perhaps going to be fixed soon.
    * Most people are reusing Radius instead of Diameter. No 
      documents to do Key Distribution. IESG is holding up Diameter 
      because security concerns haven't been addressed.
    * SIP is beginning to use Radius. SIP has pushed back against 
      Diameter. SIPPING also is pushing back against Diameter. 
      SIPPING is expressing interest in writing SNMP v3 MIBs for 
      accounting. Cellular requirements are influencing Diameter. 
      PPVPN is looking at using AAA.
    * Margaret reported on IPv6 Operations - they are focusing on 
      coexistence, not transition. Currently analyzing scenarios for 
      3GPP and unmanaged networks; they want more input for 
      Enterprise and ISP networks. They believe that both 3GPP and 
      unmanaged networks need a dual stack.

Hypothesis: the IETF is lacking an overall vision for how different
efforts can cooperate and work together. Perhaps the NMRG could
help by providing a technical vision that would help the ADs focus
the various WGs. Other ideas were to develop a session based
security model as well as a common bootstrap model.

ITEM: SMIng Discussion
  * Since the SMIng WG is going to be closed down, these documents 
    will be published by the NMRG. Olivier and Emmanuel developed a 
    proxy agent which implements Juergen's and Frank's draft. They 
    wanted to demonstrate the co-existence of SMIng and COPS-PR.
  * SMIng objects for usage by management applications that only 
    operate on SMIng objects.
  * With SNMP, you can easily turn SNMP instance data into a set of 
    SMIng objects. Might be possible to get the SMIng updates into
    the implementation. Note, however, that if there are no follow-on 
    projects from industries or fora, this work might be stopped.
  * Dave Perkins asks how much semantic checking is being done, and 
    whether there is a list of ambiguities. It would also be good to 
    have the INRIA implementation consistent with the final SMIng 
    documents. However, it is unlikely that libsmi will be upgraded
    to support the final SMIng document any time soon, since the 
    INRIA implementation uses Java CC.
  * Action items:
    * Emmanuel will talk to Frank to get comments integrated into the 
      current documents
    * Frank will contact COPS-PR mapping authors to see how we can
      update this document

ITEM: SMI XSD translation and gateway
  * Torsten started discussion of this topic by using his IM 
    presentation ("Towards XML-Oriented Internet Management"). 
    Following are notes from his presentation:
    * SNMP Problems - a "low-level" technology, quite complicated, 
      requires expensive experts. Also, it is difficult to move 
      configuration between devices. Programming is done by side 
      effect (e.g., set variables without clear semantics). XML may 
      be the way out? Torsten's work depended on XML Schemata, since 
      through that it could ensure the integrity of XML documents 
      through formal grammars. Note that the "proprietary database of 
      SNMP data" phrase on slide 4 causes some lively discussion. :)
    * Mapping MIB Definitions to XML Schema Definitions is inherently 
      difficult. This is because there is no form for creating 
      standardized instance data from SMI. There are also many 
      differences between producing a database of SNMP data (from 
      MIBs based on the SMI) versus producing an XML document (based
      on XSDs). Furthermore, it is important to note that there is not 
      a standard interchange format to exchange instance data even if 
      two devices support the same MIB. Thus, the approach is to 
      follow the XML style as close as possible, but keep supporting
      automatic translations. This would save investments on MIB 
      definitions and implementations.
    * It is desired (by the authors) to have multiple "contexts" per 
      XML Document. Examples of contexts may be per agent (e.g., IP 
      Address, hostname or port), per-agent communities, or multiple 
      points in time. Each of these can be their own context tag.
    * Problem - there are security issues - for example, since 
      everything is text based, how can you secure one community from 
      the other? This is a topic for future work.
    * The authors have developed a four-level element nesting. They
      use XML Namespaces to Identify Modules. Each MIB is compiled to 
      separate XML Schema that defines an associated namespace;
      imports from MIB modules are translated to imports of 
      namespaces. Elements can be uniquely identified with namespace
      prefixes.
    * Slide 9 - the SMI is bad, in that you can change enum values
      per revision of the MIB, leading to ambiguous data. Hopefully 
      the XML mapping won't allow this?
    * Some suggestions for improving the structure of the document
      were given, including the use of complex types and a better 
      explanation of how XPath or XQuery would be used to search 
      within the documents.
    * Applications of this are potentially very powerful, and include 
      configuration management (moving configuration data between 
      devices and managers), notification processing (post-processing 
      notifications that are stored as XML documents); agent 
      validation (validating agent implementations of MIBs); SNMP/XML 
      gateway (translate HTTP requests on XML documents to SNMP 
      operations)

  * The following are comments given to the authors by the group:
    * Dave Harrington asks whether storing communities in the XML is 
      not a security issue.
    * Dave Perkins asks what is being done about different versions
      of MIB modules. The SMIv2 allows to change names of named 
      numbers which means the value representation might legally 
      change between different MIB module revisions.
    * There are corner cases of OCTET STRING display hints which are 
      not reversible. (Juergen might be able to find an example in his 
      mailing list archives.)
    * Some information is lost in the translation (descriptors of 
      intermediate node, OID identities and constants).
    * Dave Perkins asked whether it was considered to move index 
      values into an index element rather than using XML attributes. 
      Furthermore, the xpath example misses namespaces and looks 
      nicer than it would be if it were spelled out.
    * Aiko asks whether the xpath filter interpreter really belongs 
      into the gateway or not better into the management application 
      using the gateway. Dave Perkins says that data might be stored
      in the gateway and updated regularly by a poller so that time
      domain queries are possible.
    * Both Daves think more future work is needed.
    * Bert asks what Frank's experiences are with writing XML Schema 
      definitions. 

DAY TWO
Juergen gave a quick summary of yesterday's meeting for the new 
people arriving. Bert was asked for further clarification on his view 
on MIBs. Bert stated that writable objects for MIBs were no longer 
required, but if the working group deemed them appropriate, then they 
should be designed that way. Bert's concern is that operators are not 
using SNMP or COPS-PR - therefore, writeable objects and configurable 
MIBs are probably not appropriate. People expressed to Bert a feeling 
that constructing writable objects were discouraged. Bert responded 
that he was concerned that operators would not use writable objects; 
however, so long as the target audience needed writable objects, go 
ahead. This is why he used the word "discouraged". Bert thinks that 
he should probably make a clearer expression, perhaps through an I-D, 
defining this.

Bert said that NetConf will likely be started. However, one of his 
issues is finding the proper chairs. One of the chairs MUST be an 
operator. Regarding delaying work on the data model, Bert still is not 
sure whether an additional working group focused on data modeling 
should be chartered or whether this work should be added into 
NetConf.

Bert clarified that with respect to SMI fixes/evolution, they had 
tried very hard not to do SMI 2.1 because people had expressed the 
need for "more". However, SMIng has failed, so it appears that the 
best thing is to simply go to a working group focused on maintenance 
mode.

We reviewed Torsten's paper again. It was observed that there needs 
to be a translation layer that will convert the MIB into the native 
objects required by the device. There is data that can be obtained
from standard MIBs and even agents. However, there is no standard way 
to exchange or interoperate.

ITEM: XMLCONF discussion
  * Phil starts with giving a presentation about XMLCONF.
  * Problem to solve directed at manual typing or usage of expect 
    scripts. 50% of outages that triggered SLA violations at AOL were 
    due to manual configuration errors. In addition, there is a fear 
    that when an OS is upgraded, configurations will break in 
    different ways.
  * Juniper has never had a customer request to enable SNMP writes.
  * Strategy - enable implementation to mirror native capabilities of 
    the device. XML enables tight integration with CLI. Moreover, XML 
    is all about data portability. XML works as conversion language 
    between database and devices.
  * Phil's slide titled "The Real World" should really be called "The 
    Ideal World". NetConf is the line that can enable the transport 
    to the device. Juniper has very few customers that operate like 
    the "ideal world" model where the authoritative information is 
    kept in a central database and all changes have to be made in the 
    central database to be pushed to the devices.
  * NextHop Technologies, Cisco, Laurel or Foundry, Wind River, 
    Juniper, RiverStone, and Intelliden all have XML APIs. Feedback 
    from the NMRG is that the draft appears to be too full of 
    compromises (i.e., the optional features that really need to be 
    mandatory).
  * Dave Perkins said that XMLCONF is very different because there is 
    an explicit asynchronous notification channel which is bound to a 
    session. Additional channels might be added to support 
    distribution of binary software images or for retrieval of 
    statistics.
  * George says that XMLCONF could be improved by looking more at 
    existing management protocols.
  * Remember that currently, the main focus of NetConf is 
    configuration. Quite a bit more work is required to turn it into
    a complete management protocol.
  * Dave Perkins explains on the white board why getting access to
    SNMP notifications is hard for management application writers.
  * Olivier asks whether there is a mechanism to subscribe to certain 
    sets of notifications. Currently, XMLCONF does not have this 
    capability.
  * Juergen makes a statement that design decisions seem to be made 
    out of feelings rather than being based on hard facts. For 
    example, is BEEP as a transport a good viable choice? Is the home 
    grown RPC layer really better than any of the existing layers?
  * A lengthy discussion ensues about SOAP vs. XMLCONF RPC and BEEP 
    vs. SSH/TLS and the various implications on the manager/agent 
    side. There is a tension between what the best technology is 
    (e.g., the ongoing BEEP, SOAP, WSDL, et. al. arguments) versus 
    what technologies the operators are currently using. On the one 
    hand, we are a research group. On the other hand, we need to stay 
    relevant.

ITEM: Action items
  * Emmanuel will talk to Frank to get comments integrated into the 
    revised SMIng documents
  * Frank will contact COPS-PR mapping authors to see how they can 
    update this document
  * Torsten's and Frank's slides will be made available on the NMRG  
    web site
  * Aiko will finish the minutes of the last NMRG meeting this week!
  * Dave Perkins will explain what a common model for booting is 
    before the IM 2003 NMRG meeting and try to document things in 
    written words
  * Phil to send his slides to the NMRG
  * Documentation of compression etc. work (Aiko, Juergen)
  * John Strassner to produce final minutes from the notes taken

ITEM: Possible future NMRG items

  * Work on the network management vision that some people think is 
    missing
  * Develop a session based security mechanism that integrates with
    AAA
  * Develop a common model for booting
  * Investigate XMLCONF design decisions and their implications, such 
    as protocol mappings and RPC mechanisms
  * Map XMLCONF onto SOAP and prove that it does work (or does not 
    work)
  * Experiment with Web Services for management (IF-MIB done as Web 
    Services), Web Services toolkits, and prototypes that enable 
    comparison of different functionality between web services vs. 
    current management approaches
  * How to manage IPv6 networks
  * Management of upcoming technologies (e.g., VPNs)
  * Disappearing management and increased dependability - reduce the 
    amount of management that is required while increasing the 
    dependability of our networks
  * Cooperative (peer-to-peer) management rather than hierarchical 
    management

The Meeting adjourned.

--FCuugMFkClbJLl1L--

Date: Thu, 26 Jun 2003 13:18:49 +0200
From: Aiko Pras <[email-masked]>
To: "[email-masked]" <[email-masked]>
CC: Aiko Pras <[email-masked]>
Subject: [nmrg] Draft minutes of the 11th IRTF-NMRG meeting
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------060303020804080402080206
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Dear all

Attached you'll find the (draft) minutes of the 11th IRTF-NMRG meeting 
(September 2002, Osnabrueck). Since I'll go on holiday tomorrow, I'll check 
on the NMRG mailing list after I return if any textual improvements have 
been proposed.

Bye

Aiko

--------------060303020804080402080206
Content-Type: text/plain;
 name="Draft_minutes_11th_NMRG_meeting.txt"
Content-Transfer-Encoding: 8bit
Content-Disposition: inline;
 filename="Draft_minutes_11th_NMRG_meeting.txt"

11th NMRG meeting
Schloß Osnabrück, Germany
September 15-16, 2002

List of participants:
   1. Randy Bush (ATT, USA)
      IETF Area Director
   2. Olivier Festor (Loria, France)
   3. Mario Jeckle (Daimler-Chrysler, Germany)
      W3C Web Service Architecture WG
   4. Jean-Philippe Martin-Flatin (CERN, Switzerland)
   5. Dave Perkins (Riverstone, USA)
   6. Aiko Pras (University of Twente, Netherlands)
   7. Jürgen Schönwälder (University of Osnabrück, Germany)
   8. Phil Shafer (Juniper Networks, USA)
   9. Frank Strauss (Technical University of Braunschweig, Germany)
  10. Margaret Wasserman (Windriver, USA)
  11. Bert Wijnen (Lucent, Netherlands)
      IETF Area Director

1) Opening
----------
A number of guests were invited for this meeting. To know each other,
the meeting started with the roll-call.

Minutes:
Frank and Juergen agreed to take notes, Aiko agreed to later turn
these notes into meeting minutes. (Remark: after the meeting also
Margaret gave her notes. Although the meeting minutes are based on
Frank, Juergen and Margaret's notes, certain details have been
omitted. Since all notes have been distributed over the NMRG
mailing-list, readers interested in every detail should take a look
at these notes.)

Purpose of the meeting:
At the last IRTF meeting in Pisa we discussed future directions 
in NM. At that meeting we agreed to organize a next meeting to 
discuss the merits of using web-services / XML for NM. In the 
meantime, the IAB has organized a workshop to discuss future 
directions for NM. At that workshop it was concluded that we 
should further investigate the use of XML for management. In 
addition, a BOF was organized at the Yokohama IETF to discuss 
the use of XML in device management. The purpose of this 
meeting is to discuss the advantages of using 
web-services / XML for management.

Agenda:
It was agreed to concentrate the first day on web-services, and the
second on XML.

2) WEB-SERVICES
---------------
Several topics related to web-services based management were
discussed. Although we took the freedom to jump from topic to topic,
the main conclusions of the discussion are summarized below.

2A) Presentations
----------------
To make the other attendees clear why someone believes that web-
services will (not) become important for Internet management, every
attendee was requested to give a short presentations.

  - Juergen:
    Does not believe in Web-Services in the interface between devices
    and management applications, because of complexity and performance
    issues and not really addressing the requirements such as
    transactions across devices.

  - Randy:   
    Believes the problem is ill defined and Web-Services is more a
    technology looking for a problem. Randy thinks that distributed
    database technology has probably more in common with the real
    requirements. He also has concerns that UDDI has serious security
    issues.

  - Margaret: 
    Margaret talks about layers in management systems and there might
    be some use of Web-Services at the higher layers. But they seem to
    be overkill at the management application - device interface. Web-
    Services might be useful for higher layers (such as service
    management layers).

  - Phil:
    Web-Services is too complex for the device interface. He wants to
    have a connection oriented, persistence technology. SOAP is
    considered too complex and has too many options. But in the end,
    he wants any RPC technology.

  - Mario:
    Mario says it was already hard to keep SOAP specifications not
    growing even faster. Web-Services are intended to bring business
    applications together and he believes Web-Services are easier to
    integrate than CORBA, DCE, ...

  - Bert:
    Bert is worried about interoperability, especially since XML is so
    easy to extend. He wants people to experiment first before
    actually trying to standardize something. He also does not think
    that Web-Services address the requirements.

  - Dave:
    Dave talks about the different viewpoints of mgmt app developers and
    device implementors. He believes that there should be different schemas 
    for data exchange between management applications and between management
    applications and devices. In case of communication to the devices, he 
    does not believe in XML and he believes that the schema must be forced
    (as with MIBs) and not provided individually by the devices 
    (as with WSDL).

  - Frank:
    Looking at configurations in an XML document format is a big win.
    An XML advantage is that there are many tools readily available,
    you just have to use them. It is easy to plug things together
    while, with SNMP, many things have to be written from scratch.
    Also need to move to an RPC style interaction mechanism.

  - Olivier:
    Web-Services can play a role between management platforms and
    within management platforms. Representing configuration as XML
    documents is really helpful. Representation of meta data etc. is
    all available with XML. Believes that representation of additional
    semantic (e.g. relationships via RDF) is a big step forward.
    Olivier believes security is still missing.

  - Jean-Philippe (J.P.):
    SNMP is good for monitoring resource constraints devices. Today
    we need to do more. Open management exists only for monitoring
    resource constraints devices. For configuration J.P. proposes
    to use XML. Within management systems and between management
    systems, you are in a distributed system and you can use CORBA,
    Web-Services, ...
    (1) Web-Service standardization is faster then CORBA
        standardization
    (2) Better separation of protocol and data ...
    (3) Web-Services is trendy and should be used in/between
        management systems

  - Aiko:
    SNMP will not be further developed substantially. Distinction
    between networks and applications starts to disappear. SNMP is not
    going to solve the bigger problems (e.g., configuration 
    management, higher-level service management, integration of 
    network-, service-, and desktop-management). Web-Services is being
    implemented and will be available in every system and application.
    Network management or monitoring is not different than any 
    other distributed applications. Web-Services will be universally 
    available and easy to use.

2B) Scenarios
-------------
A number of scenarios were identified in which web-services could play
a role. To guide that discussion, the following picture was drawn:

      (--)     ^
      (DB)--- / \            NMS System
      (--)   +---+           (High-level transactions)
             /  \
            /    \
         +---+  +---+
         |   |  |   |        EMS System
         +---+  +---+        (Vendor-specific translation)
          |      /  \
          |     /    \
        +--+  +--+  +--+
        |  |  |  |  |  |     Elements
        +--+  +--+  +--+
        
The picture allows to identify multiple layers of management:
  1. Management of individual Elements: 
     - Monitoring 
       - Data collection (via polling or push model)
       - Exception Reporting
       - Fault management
     - Configuration
       - Initial Configuration
       - Modification
     - Northbound reporting (to higher layer managers)
  2. Management of multiple Elements 
  3. Communication between (EMS/NMS) Managers
  4. Integration with internal infrastructure:
  5. Integration with external infrastructure:

There was agreement that web-services will particularly be useful at
the higher layers of the picture. There was disagreement whether web-
services will also be useful for element management. We agreed that,
although web-services might be reasonable for 4/5, these scenarios are
outside the scope of this meeting.

2C) Key technologies for web-services
-------------------------------------
With the help of Mario the following conclusions were drawn:
  SOAP             - MUST
  UDDI             - MAY sometimes be useful
  WSDL             - SHOULD (closely related to XML Schema)
  WS Architecture  - we do not know that this time
  XML RPC          - NOT (is an alternative, and will be discussed
                     tomorrow)
  XML Schema       - SHOULD (closely related to WSDL)
  LDAP             - NO (implementation detail)
  HTTP             - Not necessarily (SOAP is transport independent,
                     we need SOME transport protocol)
  DBMS             - NO

It is noted that there is a political issue with UDDI. MS and IBM have
handed over UDDI to Oasis, so W3C is not doing its own work on
discovery. The W3C architecture group will still need to reference a
discovery mechanism.

2D) Granularity of WSDL primitives (operations)
-----------------------------------------------
The following basic approaches were identified:
1.  Coarse granularity, defining very simple WSDL methods.
    Examples of such methods are: Get and Set
    (WBEM of the DMTF takes this approach). 
    The management data should be defined in XML schema.
2.  Medium granularity, in which we have more extensive, but still a 
    generic set of methods.
    Examples of such methods are: GetTable, Add, Delete, Action (a la
    CMIP), GetConfig, SetConfig (AKA dump & restore).
    Also in this case management data should be defined in XML schema.
3.  Fine granularity, in which we define object-specific methods.
    Examples of such methods are: GetRoutingTable, GetIfInOctets.
    In this case there is no need for additional XML schema.

One issue that influences the choice between these approaches, is the
possibility to support vendor extensions and interoperability. With (1)
and (2), vendor extensions can be accomplished in the XML schema. With
(3) vendor extensions require extensibility features in the WSDL
definitions. The question was raised how much interoperability we want
to encourage. There is a trade-off between flexibility and
interoperability. With XML schemas, extensibility is possible since
you can add new stuff in new namespaces and you can mix several
namespaces within an XML document.
There was some feeling that we should allow extensibility of the data
model (1 and 2), but not extensibility of the commands/operations (3).

But even in case of approach 1 and 2, it may be complicated to extend
the XML schemas underlying the WSDLs. For example, how to deal with
major changes? What about versioning? Although versioning is part of
the architecture, it will not happen to be in WSDL before 1.3.

2E) Transactions
----------------
For configuration management it is important to have support for
transactions. The question was therefore raised whether WSDL includes
support for transactions. Mario answered that that is not the case;
transaction handling (called orchestration in W3C-speak) is defined as
part of some proprietary protocols. Originally IBM defined WSFL, and
MS XLANG. IBM and MS recently joined both proposals: BPEL. Within
OASIS, there is a proposal for transaction support. Also W3C is
thinking about establishing a working group on transactions.

2F) Instance data
-----------------
In case of course granularity, the operations are defined in the WSDL
file and the (management) information is defined in XML schema.
Olivier brings up the issue of selecting specific information within an
XML document, for example to isolate information related to a specific
object instance (such as row 3 of the ifTable). One way of doing this
would be to use XPATH (XQuery may also be possible). With XPATH,
indexed information can be accessed using predicates. If, for example,
we have:
  <system>
    <interfaces>
      <ifTable>
        <row>1
         ...
        <row>3
         ...
        <row>4
         ...
The XPATH expression: 
  system/interfaces/ifTable[row=3]
returns the attribute values of that row (if we want its definition,
we can use @row). XPATH also allows to specify multiple elements in
the predicate part.

2G) Performance
---------------
Since XML is verbose, web-services may require a non-trivial amount 
of bandwidth. If compression is used, bandwidth consumption can be 
reduced at the price of CPU cycles. Mario informs us of a study that 
shows that SOAP (with compression) performs well, provided the 
document is not too small (compression factors of 1:8 till 1:20 
seem possible). Compared to SNMP, Dave is willing to accept a 
small factor of bandwidth increase (e.g. 2) but not a magnitude 
(e.g. 10) or more. Frank regards increased bandwidth and delay 
for infrequent operations to be tolerable, but not for small 
frequent requests/responses. Randy points out that, especially 
in case of out-of-band networks for management, bandwidth may 
remain to be a bottleneck. 

Compared to SNMP (over UDP), web-services have the advantage that more
data can be packed into a single message. As a result, less
interactions may be required, reducing the total time to retrieve bulk
data. Although this may be an advantage in many cases, configuration
management, which is one of the main topics to be solved, is usually
not time-critical.

Compared to SNMP, all attendees expect that web-services will put a
stronger load on the system (unfortunately there are no studies that
compare both approaches). In case of manager platforms, it may still
be cheaper, however, to increase the processing power of that
platform, compared to the costs of increasing bandwidth. In case of
network elements, it may be expensive or even impossible to upgrade
processors. The meeting felt that CPU consumption will remain to be
an important issue.

From: Frank Strauss <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [nmrg] upcoming nmrg meeting
Date: 24 Jun 2003 18:36:14 +0200
Lines: 9
Sender: [email-masked]

Hi!

Juergen> What I need next is information about who is going to attend
Juergen> and if you have any preferred topics to discuss. Please drop
Juergen> me note, also if you are yet undecided.

I am going to attend the meeting.

 -frank

content-class: urn:content-classes:message
Subject: RE: [nmrg] upcoming nmrg meeting
Date: Tue, 24 Jun 2003 12:00:38 -0400
From: "Harrington, David" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

I plan to attend

dbh

> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:[email-masked]] 
> Sent: Tuesday, June 24, 2003 8:57 AM
> To: [email-masked]
> Subject: [nmrg] upcoming nmrg meeting
> 
> 
> I am organizing the next NMRG meeting to be held on 
> Friday/Saturday after 
> the IETF meeting in Vienna as discussed before on this list. Our local
> host is the Forschungszentrum Telekommunikation Wien (FTW) [a rough
> translation would be something like telecommunication research center 
> Vienna]. I have asked our host to reserve a room for us from 
> 9:00-17:00
> on both days and I am sure they will do a good job for us.
> 
> What I need next is information about who is going to attend and if
> you have any preferred topics to discuss. Please drop me note, also
> if you are yet undecided.
> 
> /js
> 
> -- 
> Juergen Schoenwaelder		    International University Bremen
> <http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 
> 28725 Bremen, Germany
> -- 
> !! This message is brought to you via the `nmrg' mailing list.
> !! Please do not reply to this message to unsubscribe. To 
> unsubscribe or adjust
> !! your settings, send a mail message to 
> <[email-masked]>
> !! or look at https://www.ibr.cs.tu-bs.de/mailman/listinfo/nmrg.
> 

To: [email-masked]
From: Wes Hardaker <[email-masked]>
Organization: Sparta
Date: Tue, 24 Jun 2003 08:32:00 -0700
Subject: [nmrg] Re: nmrgupcoming nmrg meeting
Sender: [email-masked]

>>>>> On Tue, 24 Jun 2003 14:57:02 +0200, Juergen Schoenwaelder <[email-masked]> said:

Juergen> What I need next is information about who is going to attend
Juergen> and if you have any preferred topics to discuss. Please drop
Juergen> me note, also if you are yet undecided.

I'll be attending for once.

-- 
Wes Hardaker
Sparta

Date: Tue, 24 Jun 2003 14:57:02 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [nmrg] upcoming nmrg meeting
Sender: [email-masked]

I am organizing the next NMRG meeting to be held on Friday/Saturday after 
the IETF meeting in Vienna as discussed before on this list. Our local
host is the Forschungszentrum Telekommunikation Wien (FTW) [a rough
translation would be something like telecommunication research center 
Vienna]. I have asked our host to reserve a room for us from 9:00-17:00
on both days and I am sure they will do a good job for us.

What I need next is information about who is going to attend and if
you have any preferred topics to discuss. Please drop me note, also
if you are yet undecided.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

To: "Harrington, David" <[email-masked]>
Cc: "David T. Perkins" <[email-masked]>, <[email-masked]>
From: Wes Hardaker <[email-masked]>
Organization: Network Associates Laboratories
Date: Tue, 17 Jun 2003 17:14:47 -0700
Subject: [nmrg] Re: nmrgSecurity interaction?
Sender: [email-masked]

>>>>> On Tue, 17 Jun 2003 13:23:29 -0400, "Harrington, David" <[email-masked]> said:

[sentences edited out of order on purpose]

David> Even with an Inform, all tyhe receiver must do is acknowledge
David> receipt of the message.

Yes, but that would be a pretty useless notification receiver ;-).

The point being is that a functional notification receiver will act on
the incoming notification (if nothing else, but to log it.  Possibly
do more like send an email or pager alert or run some program or ...).
When you start doing things like that, authorization security becomes
critical.

David> The authorization model at the receiver is simple - the
David> receiver is not required to do anything with the data.

This, IMHO, is what is broken from a security perspective.  If a
notification receiver is not supposed to do any authorization security
checks then it must assume that whoever is sending it must be doing so
securely.  IE, notification receivers are not even supposed to make
sure that the incoming request is at least authenticated?  I hope you
never get your notification receiver pegged with enough
unauthenticated notifications that you have to turn your pager off for
the day due to the DOS attack via unauthenticated requests.  (note
that a primary reason for doing a DOS attack even for a log would be
to hide really important notifications in the middle of all the
illegitimate notifications).

-- 
Wes Hardaker
Network Associates Laboratories

Date: Tue, 17 Jun 2003 11:08:35 -0700
To: "Harrington, David" <[email-masked]>, "Wes Hardaker" <[email-masked]>
From: "David T. Perkins" <[email-masked]>
Subject: RE: [nmrg] Re: nmrgSecurity interaction?
Cc: <[email-masked]>
Sender: [email-masked]

--=====================_13405746==.ALT
Content-Type: text/plain; charset="us-ascii"

HI,

David - I know the authorization model in SNMPv3. It's not whether or
not one can code it. It's whether or not after applying (using it)
on the agent that your management application can "work". It seemed
like rule based applications might need "more information" to be
able to run through the rules to get meaningful results. It's a
question of how much info do you need on the incoming side
of the inference/correlation engine, and then whether or not
you need authorization rules on the output side of the 
inference/correlation engine.

At 01:23 PM 6/17/2003 -0400, Harrington, David wrote:
>Hi,
> 
>There is a standardized authorization model for notifications in SNMPv3. 
> 
>Authorization should be defined relative to the data sensitivity, and the data is associated with the agent, not the manager. If the manager wants to add supplemental authorization/filtering rules it can, but the agent should know which notifications to send, what varbinds should be included (and not send the notification if the notification varbinds are not allowed), who the notifications go to, and where to send them. 
> 
>A notification with "out of view" varbinds does not get sent. See RFC3413, section 3.3 (2).
> 
>The authorization model at the receiver is simple - the receiver is not required to do anything with the data. Even with an Inform, all tyhe receiver must do is acknowledge receipt of the message.
> 
>dbh
>-----Original Message-----
>From: Wes Hardaker [mailto:[email-masked]]
>Sent: Monday, June 16, 2003 5:05 PM
>To: David T. Perkins
>Cc: [email-masked]
>Subject: [nmrg] Re: nmrgSecurity interaction?
>
>>>>>> On Mon, 16 Jun 2003 13:41:03 -0700, "David T. Perkins" <[email-masked]> said:
>
>David> Can a polled and an exception-based management approach use the
>David> same authorization implementation?
>
>David> It sort of seems like the exception-based management approach must
>David> have all of the authorization rules in the management platform,
>David> and apply them after processing the event reports before the
>David> results are provided to the user.
>
>Events are often different from requests, so they're hard to compare.
>I've often been disappointed that no one has made a standardized
>authorization model for SNMP notifications (especially when actions
>are to be triggered by in incoming notification).
>
>They likely can use similar models (IE, similar filtering-concepts can
>be used), but I'd suspect that they'd have to be rather different
>otherwise.
>
>Consider a SNMP notification.  If you remove the varbinds that are
>"out-of-view" you may end up with an entirely different message than
>was intended to be received.  In fact, the removal of that information
>may actually make the decision based on it do something really bad.
>
>Also, event-based management would definitely need to make
>authorization decisions based on where it came from ("what address or
>network"), not just who sent it ("dave").  You'd want different
>actions to be triggered depending on where something came from.  You
>certainly wouldn't want a less-secure device to trigger an action that
>affected the more secure devices.
>
>--
>Wes Hardaker
>Network Associates Laboratories
Regards,
/david t. perkins 
--=====================_13405746==.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<body>
HI,<br><br>
David - I know the authorization model in SNMPv3. It's not whether
or<br>
not one can code it. It's whether or not after applying (using it)<br>
on the agent that your management application can &quot;work&quot;. It
seemed<br>
like rule based applications might need &quot;more information&quot; to
be<br>
able to run through the rules to get meaningful results. It's a<br>
question of how much info do you need on the incoming side<br>
of the inference/correlation engine, and then whether or not<br>
you need authorization rules on the output side of the <br>
inference/correlation engine.<br><br>
At 01:23 PM 6/17/2003 -0400, Harrington, David wrote:<br>
<blockquote type=cite class=cite cite><font face="arial" size=2 color="#0000FF">Hi,</font><br>
&nbsp;<br>
<font face="arial" size=2 color="#0000FF">There is a standardized
authorization model for notifications in SNMPv3. </font><br>
&nbsp;<br>
<font face="arial" size=2 color="#0000FF">Authorization should be defined
relative to the data sensitivity, and the data is associated with the
agent, not the manager. If the manager wants to add supplemental
authorization/filtering rules it can, but the agent should know which
notifications to send, what varbinds should be included (and not send the
notification if the notification varbinds are not allowed), who the
notifications go to, and where to send them. </font><br>
&nbsp;<br>
<font face="arial" size=2 color="#0000FF">A notification with &quot;out
of view&quot; varbinds does not get sent. See RFC3413, section 3.3
(2).</font><br>
&nbsp;<br>
<font face="arial" size=2 color="#0000FF">The authorization model at the
receiver is simple - the receiver is not required to do anything with the
data. Even with an Inform, all tyhe receiver must do is acknowledge
receipt of the message.</font><br>
&nbsp;<br>
<font face="arial" size=2 color="#0000FF">dbh</font><br>

<dl>
<dd><font face="tahoma" size=2>-----Original Message-----<br>

<dd>From:</b> Wes Hardaker
[<a href="mailto:[email-masked]" eudora="autourl">mailto:[email-masked]</a>]<br>

<dd>Sent:</b> Monday, June 16, 2003 5:05 PM<br>

<dd>To:</b> David T. Perkins<br>

<dd>Cc:</b> [email-masked]<br>

<dd>Subject:</b> [nmrg] Re: nmrgSecurity interaction?<br><br>
</font>
<dd>&gt;&gt;&gt;&gt;&gt; On Mon, 16 Jun 2003 13:41:03 -0700, &quot;David
T. Perkins&quot; &lt;[email-masked]&gt; said:<br><br>

<dd>David&gt; Can a polled and an exception-based management approach use
the<br>

<dd>David&gt; same authorization implementation?<br><br>

<dd>David&gt; It sort of seems like the exception-based management
approach must<br>

<dd>David&gt; have all of the authorization rules in the management
platform,<br>

<dd>David&gt; and apply them after processing the event reports before
the<br>

<dd>David&gt; results are provided to the user.<br><br>

<dd>Events are often different from requests, so they're hard to
compare.<br>

<dd>I've often been disappointed that no one has made a 
standardized<br>

<dd>authorization model for SNMP notifications (especially when
actions<br>

<dd>are to be triggered by in incoming notification).<br><br>

<dd>They likely can use similar models (IE, similar filtering-concepts
can<br>

<dd>be used), but I'd suspect that they'd have to be rather
different<br>

<dd>otherwise.<br><br>

<dd>Consider a SNMP notification.&nbsp; If you remove the varbinds that
are<br>

<dd>&quot;out-of-view&quot; you may end up with an entirely different
message than<br>

<dd>was intended to be received.&nbsp; In fact, the removal of that
information<br>

<dd>may actually make the decision based on it do something really
bad.<br><br>

<dd>Also, event-based management would definitely need to make<br>

<dd>authorization decisions based on where it came from (&quot;what
address or<br>

<dd>network&quot;), not just who sent it (&quot;dave&quot;).&nbsp; You'd
want different<br>

<dd>actions to be triggered depending on where something came from.&nbsp;
You<br>

<dd>certainly wouldn't want a less-secure device to trigger an action
that<br>

<dd>affected the more secure devices.<br><br>

<dd>--<br>

<dd>Wes Hardaker<br>

<dd>Network Associates Laboratories</blockquote>
</dl>Regards,<br>
/david t. perkins</body>
</html>

--=====================_13405746==.ALT--

content-class: urn:content-classes:message
Subject: RE: [nmrg] Re: nmrgSecurity interaction?
Date: Tue, 17 Jun 2003 13:23:29 -0400
From: "Harrington, David" <[email-masked]>
To: "Wes Hardaker" <[email-masked]>, "David T. Perkins" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C334F5.2B69A1F8
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,
=20
There is a standardized authorization model for notifications in SNMPv3. =

=20
Authorization should be defined relative to the data sensitivity, and =
the data is associated with the agent, not the manager. If the manager =
wants to add supplemental authorization/filtering rules it can, but the =
agent should know which notifications to send, what varbinds should be =
included (and not send the notification if the notification varbinds are =
not allowed), who the notifications go to, and where to send them.=20
=20
A notification with "out of view" varbinds does not get sent. See =
RFC3413, section 3.3 (2).
=20
The authorization model at the receiver is simple - the receiver is not =
required to do anything with the data. Even with an Inform, all tyhe =
receiver must do is acknowledge receipt of the message.
=20
dbh

-----Original Message-----
From: Wes Hardaker [mailto:[email-masked]]
Sent: Monday, June 16, 2003 5:05 PM
To: David T. Perkins
Cc: [email-masked]
Subject: [nmrg] Re: nmrgSecurity interaction?

>>>>> On Mon, 16 Jun 2003 13:41:03 -0700, "David T. Perkins" =
<[email-masked]> said:

David> Can a polled and an exception-based management approach use the
David> same authorization implementation?

David> It sort of seems like the exception-based management approach =
must
David> have all of the authorization rules in the management platform,
David> and apply them after processing the event reports before the
David> results are provided to the user.

Events are often different from requests, so they're hard to compare.
I've often been disappointed that no one has made a standardized
authorization model for SNMP notifications (especially when actions
are to be triggered by in incoming notification).

They likely can use similar models (IE, similar filtering-concepts can
be used), but I'd suspect that they'd have to be rather different
otherwise.

Consider a SNMP notification.  If you remove the varbinds that are
"out-of-view" you may end up with an entirely different message than
was intended to be received.  In fact, the removal of that information
may actually make the decision based on it do something really bad.

Also, event-based management would definitely need to make
authorization decisions based on where it came from ("what address or
network"), not just who sent it ("dave").  You'd want different
actions to be triggered depending on where something came from.  You
certainly wouldn't want a less-secure device to trigger an action that
affected the more secure devices.

--
Wes Hardaker
Network Associates Laboratories
--
!! This message is brought to you via the `nmrg' mailing list.
!! Please do not reply to this message to unsubscribe. To unsubscribe or =
adjust
!! your settings, send a mail message to <[email-masked]>
!! or look at https://www.ibr.cs.tu-bs.de/mailman/listinfo/nmrg.

------_=_NextPart_001_01C334F5.2B69A1F8
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<TITLE>[nmrg] Re: nmrgSecurity interaction?</TITLE>

<META content=3D"MSHTML 6.00.2800.1170" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D941295821-16062003><FONT face=3DArial color=3D#0000ff =

size=3D2>Hi,</FONT></SPAN></DIV>
<DIV><SPAN class=3D941295821-16062003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D941295821-16062003><FONT face=3DArial color=3D#0000ff =
size=3D2>There=20
is a standardized authorization model for notifications in SNMPv3.=20
</FONT></SPAN></DIV>
<DIV><SPAN class=3D941295821-16062003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN><SPAN class=3D941295821-16062003><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D941295821-16062003><FONT face=3DArial color=3D#0000ff =

size=3D2>Authorization should be defined relative to the data =
sensitivity, and the=20
data is associated with the agent, not the manager. If the manager wants =
to add=20
supplemental authorization/filtering rules it can, but the agent should =
know=20
which notifications to send, what varbinds should be included (and not =
send the=20
notification if the notification varbinds are not allowed), who the=20
notifications&nbsp;go to, and where to send =
them.&nbsp;</FONT></SPAN></DIV>
<DIV><SPAN class=3D941295821-16062003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D941295821-16062003><FONT face=3DArial color=3D#0000ff =

size=3D2>A&nbsp;notification with "out of view" varbinds does not get =
sent. See=20
RFC3413, section 3.3 (2).</FONT></SPAN></DIV>
<DIV><SPAN class=3D941295821-16062003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D941295821-16062003><FONT face=3DArial color=3D#0000ff =
size=3D2>The=20
authorization model at the receiver is simple - the receiver is not =
required to=20
do anything with the data. Even with an Inform, all tyhe receiver must =
do is=20
acknowledge receipt of the message.</FONT></SPAN></DIV>
<DIV><SPAN class=3D941295821-16062003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D941295821-16062003><FONT face=3DArial color=3D#0000ff =

size=3D2>dbh</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Wes Hardaker=20
  [mailto:[email-masked]]<BR><B>Sent:</B> Monday, June 16, 2003 5:05=20
  PM<BR><B>To:</B> David T. Perkins<BR><B>Cc:</B>=20
  [email-masked]<BR><B>Subject:</B> [nmrg] Re: nmrgSecurity=20
  interaction?<BR><BR></FONT></DIV><!-- Converted from text/plain format =
-->
  <P><FONT size=3D2>&gt;&gt;&gt;&gt;&gt; On Mon, 16 Jun 2003 13:41:03 =
-0700,=20
  "David T. Perkins" &lt;[email-masked]&gt; =
said:<BR><BR>David&gt; Can a=20
  polled and an exception-based management approach use the<BR>David&gt; =
same=20
  authorization implementation?<BR><BR>David&gt; It sort of seems like =
the=20
  exception-based management approach must<BR>David&gt; have all of the=20
  authorization rules in the management platform,<BR>David&gt; and apply =
them=20
  after processing the event reports before the<BR>David&gt; results are =

  provided to the user.<BR><BR>Events are often different from requests, =
so=20
  they're hard to compare.<BR>I've often been disappointed that no one =
has made=20
  a standardized<BR>authorization model for SNMP notifications =
(especially when=20
  actions<BR>are to be triggered by in incoming =
notification).<BR><BR>They=20
  likely can use similar models (IE, similar filtering-concepts =
can<BR>be used),=20
  but I'd suspect that they'd have to be rather=20
  different<BR>otherwise.<BR><BR>Consider a SNMP notification.&nbsp; If =
you=20
  remove the varbinds that are<BR>"out-of-view" you may end up with an =
entirely=20
  different message than<BR>was intended to be received.&nbsp; In fact, =
the=20
  removal of that information<BR>may actually make the decision based on =
it do=20
  something really bad.<BR><BR>Also, event-based management would =
definitely=20
  need to make<BR>authorization decisions based on where it came from =
("what=20
  address or<BR>network"), not just who sent it ("dave").&nbsp; You'd =
want=20
  different<BR>actions to be triggered depending on where something came =

  from.&nbsp; You<BR>certainly wouldn't want a less-secure device to =
trigger an=20
  action that<BR>affected the more secure devices.<BR><BR>--<BR>Wes=20
  Hardaker<BR>Network Associates Laboratories<BR>--<BR>!! This message =
is=20
  brought to you via the `nmrg' mailing list.<BR>!! Please do not reply =
to this=20
  message to unsubscribe. To unsubscribe or adjust<BR>!! your settings, =
send a=20
  mail message to &lt;[email-masked]&gt;<BR>!! or look at =
<A=20
  =
href=3D"https://www.ibr.cs.tu-bs.de/mailman/listinfo/nmrg">https://www.ib=
r.cs.tu-bs.de/mailman/listinfo/nmrg</A>.<BR></FONT></P></BLOCKQUOTE></BOD=
Y></HTML>

------_=_NextPart_001_01C334F5.2B69A1F8--

To: "David T. Perkins" <[email-masked]>
Cc: [email-masked]
From: Wes Hardaker <[email-masked]>
Organization: Network Associates Laboratories
Date: Mon, 16 Jun 2003 14:04:31 -0700
Subject: [nmrg] Re: nmrgSecurity interaction?
Sender: [email-masked]

>>>>> On Mon, 16 Jun 2003 13:41:03 -0700, "David T. Perkins" <[email-masked]> said:

David> Can a polled and an exception-based management approach use the
David> same authorization implementation?

David> It sort of seems like the exception-based management approach must
David> have all of the authorization rules in the management platform,
David> and apply them after processing the event reports before the
David> results are provided to the user.

Events are often different from requests, so they're hard to compare.
I've often been disappointed that no one has made a standardized
authorization model for SNMP notifications (especially when actions
are to be triggered by in incoming notification).

They likely can use similar models (IE, similar filtering-concepts can
be used), but I'd suspect that they'd have to be rather different
otherwise.

Consider a SNMP notification.  If you remove the varbinds that are
"out-of-view" you may end up with an entirely different message than
was intended to be received.  In fact, the removal of that information
may actually make the decision based on it do something really bad.

Also, event-based management would definitely need to make
authorization decisions based on where it came from ("what address or
network"), not just who sent it ("dave").  You'd want different
actions to be triggered depending on where something came from.  You
certainly wouldn't want a less-secure device to trigger an action that
affected the more secure devices.

-- 
Wes Hardaker
Network Associates Laboratories

Date: Mon, 16 Jun 2003 13:41:03 -0700
To: [email-masked]
From: "David T. Perkins" <[email-masked]>
Subject: [nmrg] Security interaction?
Sender: [email-masked]

HI,

Here is an interesting question....

Can a polled and an exception-based management approach use the same authorization implementation? 

It sort of seems like the exception-based management approach must
have all of the authorization rules in the management platform,
and apply them after processing the event reports before the
results are provided to the user.

Has anyone thought about this?

Regards,
/david t. perkins

Date: Tue, 3 Jun 2003 12:00:00 +0200
From: Juergen Schoenwaelder <[email-masked]>
CC: [email-masked]
To: [email-masked]
Subject: Re: [nmrg] future meetings
Sender: [email-masked]

>>>>> Margaret Wasserman writes:

Margaret> Did you make any decision about this?

Looking at the feedback I received on this list and some private
messages, I conclude the following:

(a) We will not meet next to LANOMS 2003 in Brazil. Even though we
    have a nice offer to host such a meeting, I realize that the
    number of people who are actually able to go there is just too
    small.

(b) For similar reasons, we will not meet next to APNOMS 2003 in
    Fukuoka, Japan.

(c) I will organize a meeting next to the IETF in Vienna. I propose
    that we meet Friday/Saturday after the IETF. Depeding on the final
    IETF agenda, we might start on Friday morning or Friday at lunch
    time. (I prefer to start in the morning unless there is some
    serious conflict with an IETF WG meeting such as netconf.)

(d) There seems to be interest to also meet next to DSOM in October.
    NEC offered to host such a meeting which will make things rather
    simple to organize. Since there is also the NOMS 2004 TPC meeting
    next to DSOM, I have no clear idea yet where to put an NMRG
    meeting slot. But since DSOM is still some time away, I sill just
    collect more input on from you in Vienna and electronically.

So, bottom line: I plan to organize a meeting on Friday/Saturday after
the IETF in Vienna. If some of you have ideas who might be interested
to host such a meeting in Vienna, please let me know. ;-)

/js

-- 
Juergen Schoenwaelder		International University Bremen
Phone: +49 421 200 3587		P.O. Box 750 561, 28725 Bremen, Germany
Fax:   +49 421 200 3103		<http://www.iu-bremen.de/>