Subject: RE: [nmrg] Binary vs Text
From: "Andrea Westerinen" <[email-masked]>
To: "Durham, David" <[email-masked]>, "'David T. Perkins'" <[email-masked]>, <[email-masked]>
Date: Thu, 7 Nov 2002 14:55:19 -0800
List-Id: Network Management Research Group <nmrg.ibr.cs.tu-bs.de>

Check out DSML - http://www.oasis-open.org/committees/dsml/.  Most
directories said that they would support it.

Andrea

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Durham, David
Sent: Wednesday, November 06, 2002 11:41 AM
To: 'David T. Perkins'; [email-masked]
Subject: RE: [nmrg] Binary vs Text

I am not aware of any such mappings for the protocol. Although, the
directory can simply be used to store XML docs in its attributes.

Also, LDAP unlike X.500, only uses string encodings for all attribute data.
No other directly binary types are available.

It would be really nice if LDAP provided something more like XML Schema
instead of its own home-brewed schema definitions. Hummm, (LDAP using
BER)->((LDAP using XML)+XMLSchema)... I wonder, then, what would
differentiate a directory service from an XML DOM.

-Dave

> -----Original Message-----
> From: David T. Perkins [mailto:[email-masked]]
> Sent: Wednesday, November 06, 2002 11:12 AM
> To: [email-masked]
> Subject: [nmrg] Binary vs Text
>
>
> HI,
>
> I was recently reminded that LDAP uses BER encoding of ASN.1.
> Have there
> been pushes to "convert" LDAP messages to text encoding (ie XML)?
> (Or has this already happened, and I miss it?)
>
> Regards,
> /david t. perkins
>
> --
> !! 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.
>
--
!! 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.

From: Frank Strauss <[email-masked]>
To: Phil Shafer <[email-masked]>
Cc: [email-masked]
Subject: Re: [nmrg] Notification filtering and logging
Date: 07 Nov 2002 21:44:05 +0100
Lines: 27
Sender: [email-masked]

Hi!

>> When we look at management data as XML guys, I think we should prefer
>> XPath for filtering.

Phil> XPath is good technology, but implementing it on the box will
Phil> be expensive, both in terms of the technology itself and the
Phil> mapping between the underlaying commands and the data requirements
Phil> for the XPath expression. While it's attractive to think of
Phil> the device as a huge dynamic datastore, it's very costly and
Phil> brings its own inefficiencies.

>> GET /context[@name="router.nowhere.com" and @port="161" and
>> @community="public"]/IF-MIB/ifEntry[ifOperStatus='up' and
>> ((ifInErrors * 10000 > ifInOctets) or
>> (ifOutErrors * 10000 > ifOutOctets))]/ifDescr

Phil> For complex queries like this, I'd prefer to get the data off the
Phil> device and post-process it using xslt/xpath/etc.

Agreed. A student at our institute just started working on an SNMP/XML
gateway that will hopefully support such XPath expressions. One approach
would be what you suggest, but I have some hope that we will also be able
to interpret the requests (partly) so that we can reduce the Agent/Gateway
SNMP traffic to some degree.

 -frank

To: Frank Strauss <[email-masked]>
cc: [email-masked]
Subject: Re: [nmrg] Notification filtering and logging 
Date: Thu, 07 Nov 2002 15:29:45 -0500
From: Phil Shafer <[email-masked]>
Sender: [email-masked]

Frank Strauss writes:
>When we look at management data as XML guys, I think we should prefer
>XPath for filtering.

XPath is good technology, but implementing it on the box will
be expensive, both in terms of the technology itself and the
mapping between the underlaying commands and the data requirements
for the XPath expression. While it's attractive to think of
the device as a huge dynamic datastore, it's very costly and
brings its own inefficiencies.

>        GET /context[@name="router.nowhere.com" and @port="161" and
>            @community="public"]/IF-MIB/ifEntry[ifOperStatus='up' and
>            ((ifInErrors * 10000 > ifInOctets) or
>             (ifOutErrors * 10000 > ifOutOctets))]/ifDescr

For complex queries like this, I'd prefer to get the data off the
device and post-process it using xslt/xpath/etc.

Thanks,
 Phil

From: Frank Strauss <[email-masked]>
To: [email-masked]
Subject: Re: [nmrg] Notification filtering and logging
Date: 07 Nov 2002 21:19:51 +0100
Lines: 19
Sender: [email-masked]

Hi!

David> One of the appealing aspects of XML-based management is that it
David> is text-based, and, thus, reg-exs can be used for selection.

When we look at management data as XML guys, I think we should prefer
XPath for filtering. (I don't know enough about XQuery, maybe it's an
additional worthwhile approach.) XPath is able to evaluate elements,
attributes and text nodes as strings and numbers, e.g.

        GET /context[@name="router.nowhere.com" and @port="161" and
            @community="public"]/IF-MIB/ifEntry[ifOperStatus='up' and
            ((ifInErrors * 10000 > ifInOctets) or
             (ifOutErrors * 10000 > ifOutOctets))]/ifDescr

(Yes, we cannot handle wrapping counters appropriately this way, and
there are certainly further problems that cannot be addressed easily.)

 -frank

Date: Thu, 7 Nov 2002 11:24:34 +0100
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: [nmrg] Notification filtering and logging
Sender: [email-masked]

>>>>> David T Perkins writes:

David> One of the appealing aspects of XML-based management is that it
David> is text-based, and, thus, reg-exs can be used for selection.

The SMI and SNMP basically distinguished between numbers, OIDs and
(binary) strings. Regular expression matches make sense for strings,
but not really for numbers (common relational operators usually just
work fine on numbers). So from this perspective, there is really no
need to convert numbers into strings in order to do better
filtering. (And even typical databases query languages do not do this
for a good reasons.)

I think the real problem with SNMP is the OID naming system which
requires some code to unpack instance identifier in order to do
matches on them. The packing of strings and numbers into instance
identifier is really kind of ugly if you look at it from an outsider
perspective.

David> (For me, one of the features that significantly drove up the
David> cost of CMIP was support for filtering paired with defining new
David> data types. Each time a new data type was created, one had to
David> define the comparison operators. And to support the objects
David> with the new data types, one had to both add new
David> parsing/encoding functions and add comparison functions. This
David> complicated the "packaging" and complexity of management
David> toolkits, and bloat, and we all know the result.)

As you wrote, it is not the filtering (CMIP filter expressions have a
fixed and probably well-defined set of operators) which is the cost
factor, but the fact that you could add arbitrary differently encoded
data types which makes it costly. SNMP is much better in this respect.

/js

-- 
Juergen Schoenwaelder    <http://www.informatik.uni-osnabrueck.de/schoenw/>

To: "David T. Perkins" <[email-masked]>
cc: [email-masked]
Subject: Re: [nmrg] Notification filtering and logging 
Date: Wed, 06 Nov 2002 19:48:45 +0000
From: George Pavlou <[email-masked]>
Sender: [email-masked]

David,

> A next-generation replacement
> for SNMP should address this issue. Also, it seems desirable to me that
> the selection mechanism should be applicable to retrieval requests.

If a filtering mechanism for events is there, it could easily
be used to also eliminate object selection in retrievals.
And I also agree that the next generation Internet management
should provide this capability.

> One of the appealing aspects of XML-based management is that it is
> text-based, and, thus, reg-exs can be used for selection.

True, but arguably not with the flexibility and power one gets
with boolean predicates.

> (For me, one of the features that significantly drove up the cost of CMIP
> was support for filtering paired with defining new data types. Each
> time a new data type was created, one had to define the comparison
> operators. And to support the objects with the new data types, one
> had to both add new parsing/encoding functions and add comparison
> functions. This complicated the "packaging" and complexity of
> management toolkits, and bloat, and we all know the result.)

Having implemented CMIS/P filtering in the past, I can tell you
that comparison methods are provided once for fundamental types
and used thereafter. For most composite types, the only possible
comparison is equality and this was produced by our O-O ASN.1 compiler.
I admit that other possible comparisons had to be hand-coded,
but that was rare (and we implemented many type-rich MIBs).
I don't think that the reasons for the failure include
complexity of the facilities provided by the protocol/agent.

A selection of SNMP object subtrees + filtering of some kind
(the latter also applying to events) should be high in the list of
desirable features for next generation SNMP.
But unfortunately these are not the only fixes needed...

Regards,
-George

***********************************************************************
* Prof. George Pavlou                           Tel: +44 1483 689480  *
*                                               Fax: +44 1483 686011  *
* Centre for Communication Systems Research                           *
* School of Electronics, Computing and Mathematics                    *
* University of Surrey                                                *
* Guildford, Surrey GU2 7XH, U.K.                                     *
*                                                                     *
* e-mail: [email-masked]                                   *
* WWW:    http://www.ee.surrey.ac.uk/CCSR/Networks/		      *
*	  http://www.ee.surrey.ac.uk/Personal/G.Pavlou/		      *
*								      *
***********************************************************************

From: "Durham, David" <[email-masked]>
To: "'David T. Perkins'" <[email-masked]>, [email-masked]
Subject: RE: [nmrg] Binary vs Text
Date: Wed, 6 Nov 2002 11:41:21 -0800 
Sender: [email-masked]

I am not aware of any such mappings for the protocol. Although, the
directory can simply be used to store XML docs in its attributes.

Also, LDAP unlike X.500, only uses string encodings for all attribute data.
No other directly binary types are available.

It would be really nice if LDAP provided something more like XML Schema
instead of its own home-brewed schema definitions. Hummm, (LDAP using
BER)->((LDAP using XML)+XMLSchema)... I wonder, then, what would
differentiate a directory service from an XML DOM.

-Dave

> -----Original Message-----
> From: David T. Perkins [mailto:[email-masked]]
> Sent: Wednesday, November 06, 2002 11:12 AM
> To: [email-masked]
> Subject: [nmrg] Binary vs Text
> 
> 
> HI,
> 
> I was recently reminded that LDAP uses BER encoding of ASN.1. 
> Have there
> been pushes to "convert" LDAP messages to text encoding (ie XML)?
> (Or has this already happened, and I miss it?)
> 
> Regards,
> /david t. perkins
> 
> -- 
> !! 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.
> 

Date: Wed, 06 Nov 2002 11:10:10 -0800
To: [email-masked]
From: "David T. Perkins" <[email-masked]>
Subject: [nmrg] Notification filtering and logging
Sender: [email-masked]

HI,

The filtering(selection) and logging of notifications seems to be a
common requirement in many management protocols. I am seeing work 
such as the following

http://www.ietf.org/internet-drafts/draft-moran-sipping-filter-reqs-00.txt

coming from many areas within the IETF. A next-generation replacement
for SNMP should address this issue. Also, it seems desirable to me that
the selection mechanism should be applicable to retrieval requests.

One of the appealing aspects of XML-based management is that it is
text-based, and, thus, reg-exs can be used for selection. (For me,
one of the features that significantly drove up the cost of CMIP
was support for filtering paired with defining new data types. Each
time a new data type was created, one had to define the comparison
operators. And to support the objects with the new data types, one
had to both add new parsing/encoding functions and add comparison
functions. This complicated the "packaging" and complexity of
management toolkits, and bloat, and we all know the result.)

So, any reactions?

Regards,
/david t. perkins

Date: Wed, 06 Nov 2002 11:11:59 -0800
To: [email-masked]
From: "David T. Perkins" <[email-masked]>
Subject: [nmrg] Binary vs Text
Sender: [email-masked]

HI,

I was recently reminded that LDAP uses BER encoding of ASN.1. Have there
been pushes to "convert" LDAP messages to text encoding (ie XML)?
(Or has this already happened, and I miss it?)

Regards,
/david t. perkins