Subject: RE: Interim attendance survey

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Mon, 27 Mar 2006 13:20:16 +0200

Andy,

As I said I am not opposed to an interim meeting. In fact I am in favor
anything that can help us make progress. 

I would however not tightly couple holding an interim with the success
of the NETCONF notifications work, or completion of the charter and
present the interim as a 'last chance' opportunity. 

For somebody looking from the outside the NETCONF WG may seem actually
in rather good shape.  All due milestones are completed, we have an
initial submission for the only remaining charter item - notifications
and we have still six months ahead until we need to submit a
notifications document at the required level of consensus for WGLC. This
is good in IETF terms nowadays. I am aware that this good shape is
apparent, and there is little agreement on the problem space, and too
little review of the draft that includes a proposed solution even to
determine the level of agreement. I would encourage the WG to focus on
discussing the problem space (why are we doing notifications?) and the
draft and other options for solutions more intensively on the list. Let
us see in the next couple of weeks if we can reach more convergence on
the 'why' and 'how' questions. 

If we do have contributions about the scope and reviews of the draft and
solutions on the list we have a chance to better converge and reach
agreement. If the level of apathy stays the same, I am not sure that a
partially attended interim meeting would help. 

Regards,

Dan

> -----Original Message-----
> From: Andy Bierman [mailto:[email-masked]] 
> Sent: Sunday, March 26, 2006 10:01 PM
> To: Romascanu, Dan (Dan)
> Cc: Netconf (E-mail)
> Subject: Re: Interim attendance survey
> 
> Romascanu, Dan (Dan) wrote:
> > As a contributor I would like the NETCONF notification work to 
> > continue and be completed in time.
> > 
> > As AD and WG Area Advisor I would like to attend the 
> meeting. However 
> > my schedule is completely booked all May and the first days 
> of June, 
> > until 6/5. Yet, my participation is not of condition for 
> the meeting 
> > happening.
> > 
> > I prefer European venues to North-American ones. 
> 
> Me too. But it's actually a policy (AFAIK) that interim 
> meetings take into consideration recent (and next) IETF 
> locations and try to be fair.  I also think we need to be 
> practical, so I think London would be a good location.  It 
> might be easier with a local host to setup the logistics 
> (Simon and I are not located near London).
> 
> I'm not actually convinced yet this work matters enough to 
> the WG to be continued.  IMO, this is a "nice-to-have" 
> feature not a "must-have" (like a replacement for screen 
> scraping CLI w/Expect).
> 
> For many WG members, a replacement for syslog is a 
> "don't-need" feature.
> Combine "don't-need" with "nice-to-have" and the outcome isn't very
> surprising:
> 
>     -- very few people reviewed the draft
>     -- very little agreement on the problem space
>     -- no agreement on the solution
> 
> An interim meeting would be a last-ditch attempt to get 
> consensus started somewhere, before giving up.
> 
> 
> > 
> > Dan
> 
> Andy
> 
> > 
> > 
> > 
> > 
> >  
> >  
> > 
> >> -----Original Message-----
> >> From: [email-masked]
> >> [mailto:[email-masked]] On Behalf Of Andy Bierman
> >> Sent: Saturday, March 25, 2006 10:05 PM
> >> To: Netconf (E-mail)
> >> Subject: Interim attendance survey
> >>
> >> Hi,
> >>
> >>
> >> I want to do a survey to measure interest in the NETCONF 
> Notification 
> >> work.  Very few people read the draft before the meeting, 
> let alone 
> >> reviewed it, despite numerous pleas.
> >>
> >> There are 3 choices (option 4: don't care, I already know about):
> >>
> >> 1) I do not want the NETCONF notification work to continue
> >>    and I will not attend the interim meeting.
> >>
> >> 2) I want the NETCONF notification work to continue
> >>    but I will not be able to attend the interim meeting.
> >>
> >> 3) I want the NETCONF notification work to continue
> >>    and I will be able to attend some or all of the 3 day interim 
> >> meeting.
> >>
> >>
> >> Possible location: Outside North America;
> >>                    (hopefully w/ non-stop flights from all over)
> >>                    (3 IETFs in a row in NA already)
> >>
> >> Possible dates: 1 - 2 months before the Montreal IETF (May - June)
> >>
> >>
> >> Please send comments to the list.
> >>
> >>
> >> thanks,
> >> Andy
> >>
> >>
> >>
> >>
> >> --
> >> 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/>
> >>
> > 
> > --
> > 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/>
> > 
> > 
> 
> 

--
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: Mon, 27 Mar 2006 07:26:33 -0800

> present the interim as a 'last chance' opportunity.

I wasn't -- directly.
However, without an interim I think we will
be in this exact situation in Montreal.

If we have a normal interim, it will be in London in May.

There is also the possibility that the IESG will approve
my request for "Interim Friday", in which case we could
have a 3 day interim (Friday - Sunday) at the Montreal IETF instead.
IMO this is the best choice because it minimizes travel costs.

> the 'why' and 'how' questions. 

We clearly do not agree on the requirements.

> partially attended interim meeting would help. 

Maybe it would help to consider other proposals.
Maybe the WG needs to spend a couple years on a
NETCONF Notification Requirements RFC first.

I hate those RFCs, but in this case there is such a
wide array of undocumented and implied requirements in
the draft (and the WG), I don't think consensus will
ever be reached by attempting to "refine" it.

Andy

---

From: David Harrington <[email-masked]>
Date: Tue, 28 Mar 2006 12:25:39 -0600

Hi,

I would like a better understasnding of why we are doing
notifications. I am struck by what appears to me to be two very
different drivers for netconf, and the "why are we doing
notifications?" question relates to these different motivations.

I have suggested that the O&M and Security communities should work at
establishing a strategic vision about converging aspects of the
various NM protocols and NM security solutions. If this is a path
worth taking, it should be a deliberate decision to do so because
there are some real problems associated with a convergence approach.

For this reason, I would like to understand what we are trying to
achieve with netconf and the current proposal for notifications, to
determine if the goals are compatible.

If the purpose of netconf is to provide a machine-friendly,
standardized protocol to eliminate the need for screen scraping CLI
expect scripts, I am not convinced we need notifications in the
netconf protocol. I think the netconf WG has done a reasonably good
job of standardizing the operations, but to achieve the goals, we also
need to improve the parseability of the data that now needs to be
screen scraped. The parseability of the data contained in the
responses coming back must be addressed. If vendors simply take their
existing screens of data and surround them with <cli></cli> tags, then
I think we've failed to eliminate the screen-scraping problem, and
other problems identified by operators at the IAB NM workshop:

   -  Some command line interfaces lack a common data model.  It is
very
      well possible that the same command on different devices, even
      from the same vendor, behaves differently.

   -  The command line interface is primarily targeted to humans which
      can adapt to minor syntax and format changes easily.  Using
      command line interfaces as a programmatic interface is
troublesome
      because of parsing complexities.

   -  Command line interfaces often lack proper version control for
the
      syntax and the semantics.  It is therefore time consuming and
      error prone to maintain programs or scripts that interface with
      different versions of a command line interface.

   -  Since command line interfaces are proprietary, they can not be
      used efficiently to automate processes in an environment with a
      heterogenous set of devices.

   -  The access control facilities, if present at all, are often
ad-hoc
      and sometimes insufficient.

Netconf does not seem to resolve these operational disadvantages of
the CLI, and notifications aren't even mentioned as a problem to be
solved.

If the purpose of netconf is to standardzie existing practice, and
existing practice is defined as screen scraping CLI expect scripts
plus syslog notifications, then I question whether we need to include
syslog notifications in netconf; syslog works well in its special
niche, and really doesn't need to be added to netconf.

The Syslog (-security) WG has been working to standardize the message
header format. The syslog community has not reached consensus on the
need to standard message content, except to add a structured data
component. The WG had difficulty even reaching agreement on
standardizing their message header format beyond starting the message
with <PRI>. I do not believe that netconf would be more successful at
standardizing syslog content than the syslog community, so I do not
believe that standardizing syslog message content should be a
justification for adding notifications to netconf, without a long
discussion about the feasibility of accomplishing this goal. I think
the standardization of syslog belongs in a (O&M) syslog WG, not the
netconf WG (and not the syslog security WG).

If the purpose of netconf is to assimilate the functionality of older
protocols like syslog and SNMP - to integrate them into a collective
netconf structure, and to eventually replace the old protocols with a
new general purpose management protocol minus the known problems, then
netconf has a higher bar to meet in its design requirements than have
been acknowledged. SNMPv3 is complex because it needed to deal with
security issues and troubleshooting requirements and other things;
syslog does not have a standard content format because there are a
wide number of vendors protecting their space, and the demand for
backwards compatibility to all or most existing header formats has
prevented progress in the syslog (security) WG. Faced with
requirements comparable to those faced by the older protocols during
their design, I expect netconf would fail to assimilate them properly.
Therefore, if the purpose of netconf is to be a general purpose NM
protocol, we need to have a serious discussion about the requirements
that must be met to achieve successful assimilation.

I find the existing proposal has plans to assimilate other protocols -
"The purpose of this [syslog-to-netconf] mapping is to provide an
unambiguous mapping to enable consistent multi-protocol
implementations as well as to enable future migration." and to attempt
to standardize that which the syslog community has failed to
standardize - "The intent is to promote the use of the NETCONF
interface and not to simply provide a wrapper and additional delivery
mechanism for syslog messages.  NETCONF events are intended to be well
defined and structured, therefore providing an advantage over the
unstructured and often times arbitrarily defined syslog messages (i.e.
the message field)."

I am a strong supporter of judicious reuse of NM and security
solutions across NM interfaces, but I believe apparent convergence
opportunities need to be discussed and for  each convergence we need
to consider the requirements met by each protocol and whether a
converged solution continues to meet those requirements or
deliberately does not meet some requirements.

I am bothered by the fact that netconf, a configuration protocol, is
being redesigned in the current proposal to carry syslog messages that
may have nothing to do with configuration, and it is expected that
even more stuff, also possibly not related to configuration, will be
carried in a new event message format. Operators at the IAB Network
Management Workshop apparently did not find syslog sufficiently broken
to request that a new event messaging capability be designed, so I
have concerns that the current proposal includes a brand-new
notification solution.

If netconf will become the new general purpose mgmt protocol for the
IETF, we should do this deliberately, not as a side-effect of adding a
notification operation to netconf.

David Harrington
FutureWei Technologies, a Huawei company
[email-masked] 
[email-masked]
[email-masked]

> [mailto:[email-masked]] On Behalf Of Romascanu, Dan
(Dan)
> Sent: Monday, March 27, 2006 5:20 AM
> To: Andy Bierman
> Cc: Netconf (E-mail)
> Subject: RE: Interim attendance survey
> 
> [...] I am aware that this good shape is

---

From: Andy Bierman <[email-masked]>
Date: Tue, 28 Mar 2006 14:11:14 -0800

> the CLI, and notifications aren't even mentioned as a problem to be

Why not?
Because there are no standard data models yet?
The RFCs haven't even been published, so it's a bit early
to declare standard data modeling dead.

I am thrilled that so many implementations are under way
for a not-yet-published, no-port-assigned-yet protocol.
I want these implementations to continue, get deployed,
and then start with the enhancements.

The <cli> data model you mention is a natural evolutionary
step in the replacement of screen-scraping.  It provides
a way to get the protocol and error handling in place,
without giving up functionality.

This is the "wide and shallow" vs. "narrow and deep"
data model debate.  The reason every replacement
for the CLI that has been attempted has failed is
that they all attempt to deploy 1 or 2 "perfect" data models,
but most operators are not willing to use the CLI for
10000 commands and the fancy GUI for 20 more.

Although <cli> as a data model provides no depth whatsoever,
it provides 100% coverage of the CLI, plus structured error
codes, and maybe more.  Once this is in place, you can
start adding deep models for specific applications you
need to support.

> notification operation to netconf.

I agree with these last 2 paragraphs a lot.
It occurred to me when I saw an event type
for "performance metrics" notifications that
we might not all be on the same page wrt/
what netconf notifications are needed for.

I know that throughout design meetings from Day One,
only 3 notification types related to configuration came up:

   - config-change: some part of the <running> configuration changed
   - device-change: some part of the managed device changed
     (e.g., card swap)
   - direct usage of RFC 3195 (syslog over beep)

I also think that if the content of syslog is to
be standardized, that the syslog WG should do it, not netconf.
I was comfortable with throwing a beep channel for syslog
into netconf, but not standardizing an XML-based replacement
for syslog content.  I am going to ask the ADs
to "move it or lose it" wrt/ syslog content in netconf.

Since our charter says we are doing network configuration,
not a syslog replacement or an snmp replacement, I would
rather work on that.  That's what I thought I was signing
up for as co-Chair in fact.

There are lots of unsolved problems in the NM world.
If we run off trying to solve everybody else's problems,
who is going to actually work on network configuration?

Andy

---

From: Shane Kerr <[email-masked]>
Date: Wed, 29 Mar 2006 12:09:25 +0200

> notifications?" question relates to these different motivations.
<snip/>
> have concerns that the current proposal includes a brand-new

It sounds like at least one person working on syslog thinks there is
value in a brand-new notification solution, and I believe him. :)

For me the first question is whether this should be done in NETCONF or
perhaps in a new working group. I don't know too much about it, but
since the scope seems very broad, I think maybe a new working group
makes sense, and NETCONF can declare victory.

- --
Shane

---

From: Chris Lonvick <[email-masked]>
Date: Wed, 29 Mar 2006 05:11:01 -0800 (PST)

Hi,

I, too, have a concern about sending notification messages through 
netconf.

syslog is frequently the oldest piece of running code on many boxes. 
Since it works and is well understood by automated parsers, there is 
little impetus to change the log messages or the underlying protocol. 
That's a challenge that we knew about when we started the WG.

The BoFs and email threads from before the WG was formed showed that many 
people have strong opinions about how the format of a syslog message, 
including the payload, should be structured.  We figured that a WG would 
never come to consensus on that problem.  From that, the syslog WG was 
charterd in the security area to provide security mechanisms for the 
syslog protocol.  We tried working with the rather undefined header 
information but came to the conclusion that we couldn't provide a good set 
of documents without some work on standardizing the header fields.  That 
allowed us to add structured data (Rainer has described that).

When we started doing that, we also separatied the transports from the 
protocol.  The netconf WG could use that format within netconf if desired. 
This will allow the message format to be utilized within new secure 
transports as they are developed (e.g., dtls) without having to make 
changes to the message body.

If the netconf WG decides to provide notifications, we hope that the WG 
will consider the use of The syslog Protocol within whatever transports 
you decide upon.  I believe that the framework provided within The syslog 
Protocol will allow you to define message bodies as you see fit.

We are making progress on the current set of IDs within our new charter. 
We have:

For the basic protocol and transports

The syslog Protocol
http://www.ietf.org/internet-drafts/draft-ietf-syslog-protocol-16.txt

Transmission of syslog messages over UDP
http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-udp-06.txt
(this provides compatability with existing syslog/udp)

TLS Transport Mapping for SYSLOG
http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-00.txt

We are still going to provide Signed syslog Messages
http://www.ietf.org/internet-drafts/draft-ietf-syslog-sign-17.txt
as a way to ensure end-to-end security of the messages.  We are also going 
to provide a revision to RFC 3195 that supports The syslog Protocol 
(standardized headers, larger payload size, etc.).  The driver for 
revising RFC 3195 is that it is being implemented in the medical health 
industry and they do require larger payloads.

As far as the interest level goes, the IESG felt that there was enough 
support and interest to develop code to allow us to recharter.  I agree 
with that.

Thanks,
Chris