Subject: RE: NETCONF Notifications: Consensus Points

From: "Sharon Chisholm" <[email-masked]>
Date: Sun, 4 Dec 2005 13:42:41 -0500

hi

Couple points ....

The SD-Param portion of the syslog message is not that much more
economically encoded than the XML encoded one. Where you are getting all
your size savings there is the bits which defines a set of information
in a non-flexible order and encoding (no space, for example) of the
information in the message. 

We would often have these battles in SNMP MIBS, more in the proprietary
space, about well-defined fields versus opaque blobs. People liked the
opaque blobs because they allowed them to be clever and solve problems
they couldn't using SMI, but then they were often more difficult to
learn how to use and were not subjected to the same backwards
compatibility rules.

As someone more often then not ending up on the consuming end of
management information, I tend to go for clarity over performance, but I
recognize there are situations where more verbose encodings will make
certain uses of the information intractable.

Sharon

-----Original Message-----
From: Phil Shafer [mailto:[email-masked]] 
Sent: Tuesday, November 29, 2005 5:25 PM
To: Chisholm, Sharon [CAR:5K50:EXCH]
Cc: [email-masked]
Subject: Re: NETCONF Notifications: Consensus Points 

"Sharon Chisholm" writes:
>I think bringing these in, not using SD-Param
>grammar, but as properly tagged XML would be very very useful.

XML has its uses, but log data is not one of them.  We need to be
careful that we don't start seeing everything as a nail to our xml
hammer.

XML is useful for encoding hierarchical data, but is horrible for simple
flat data (try encoding a csv file in xml).  XML is good at encoding
data that is highly variable, but expensive for more normalizable data.
XML is great for data interchange, where both sides of the conversation
need to be flexible and resilient.  But it's horrible for data storage.
XML's overhead can be ignored for intermittent operations like
configuration requests, but will kill you at high volume.

Compare a notification in XML:

    <notification>
      <time seconds=234532455432345>Oct 18 16:01:37</time>
      <tag>RPD_RSVP_NBRUP</tag>
      <hostname>my-host</hostname>
      <process pid=2958>rpd</process>
      <data>
        <neighbor>10.5.14.2</neighbor>
        <interface>fe-1/3/0.0</interface>
      </data>
      <message>RSVP neighbor 10.5.14.2 up on interface
fe-1/3/0.0</message>
    </notification>

and the same data in syslog:

Oct 18 16:01:37  my-host rpd[2958]: RPD_RSVP_NBRUP: RSVP neighbor
10.5.14.2 up on interface fe-1/3/0.0

The syslog-SD form of this would be something like:

1 888 4 00 2005-10-18-16:01:37 my-host rpd 2958 RPD_RSVP_NBRUP [JNPR-0
neighbor="10.5.14.2" interface="fe-1/3/0.0"] RSVP neighbor 10.5.14.2 up
on interface fe-1/3/0.0

(That should be close enough; I'm not an SD-guru)

wc -c reports the lengths as 321, 104, and 168.

I take it as a given that customers will use notification data from
netconf in the same pattern we see with syslog data.  They configure
large volumes of data, which they store and use to investigate problems,
either real-time or port-mortem.

IMHO, the SD-PARAM version wins hands down, based on functionality .vs.
footprint.  I can filter by severity, date, msgid, and message content
parameters.  That's pretty much all I'm after.

Thanks,
 Phil

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: Andy Bierman <[email-masked]>
Date: Sun, 04 Dec 2005 12:38:32 -0800

>certain uses of the information intractable.

I think you are making valid points for the WG to consider.
IMO, it is the information model elements, not the syntax, that is 
important.
We have to agree on that model first.  The actual syntax is not as high 
priority as other
design goals, such as:
   - "keep the notification PDU the same syntax and semantics across all 
supported transports."

The text specific to syslog can be removed and replaced with text that 
says:
   - "a notification content information model and encoding will be 
selected or specified."

Can we agree on this much, update the charter text, and agree to get 
started?

>Sharon

Andy

---

From: Phil Shafer <[email-masked]>
Date: Mon, 05 Dec 2005 11:23:27 -0500

"Sharon Chisholm" writes:
>management information, I tend to go for clarity over performance

But SD-Params are clear, right?  They are name=value pairs.  We
don't need anything more than that and another WG has a wonderful
draft that we can leverage to make our work easier in three ways,
specification, implementation, and acceptance.  We incorporate the
syslog WG's work by reference, vendors leverage their new NG syslog
implementation both for syslog and for netconf, and using syslog
allows providers to leverage their new and old syslog infrastructure
and tools.

We get performance _and_ clarity.  It's simpler _and_ easier.  It's
a dessert topping _and_ a floor cleaner.

Thanks,
 Phil

---

From: "Tom Petch" <[email-masked]>
Date: Mon, 5 Dec 2005 18:24:38 +0100

---- Original Message -----
From: "Phil Shafer" <[email-masked]>
To: "Sharon Chisholm" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, December 05, 2005 5:23 PM
Subject: Re: NETCONF Notifications: Consensus Points

> a dessert topping _and_ a floor cleaner.

Sounds great but be aware that in November, the AD has issued a

"formal Consultation prior to concluding the working group"

on the grounds that consensus is unlikely to be reached.  So if you like SDs,
then sign up to syslog and agree with everything that the WG chair or Rainer
(I-D editor) proposes.  Then netconf will have an RFC to reference:-)

Tom Petch

---

From: Balazs Lengyel <[email-masked]>
Date: Tue, 06 Dec 2005 09:11:36 +0100

I would not worry so much about reuse of domain name based capability names. Has the reuse 
problem ever happened with XML namespaces ?

If someone wants a bulletproof solution he might choose a capability like 
SNMPOID:1.3.6.1.enterprises.ericsson.mycapability
This would be as unique as he can get while others (like me) can use a domain name based 
capability if we are not worried about reuse. You should have to make this mandatory just 
maybe mention it.
Balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Tel: +36-1-437-7320     email: [email-masked]