RE: [Syslog] Decisions to make about the Huawei IPR claim

Anton Okmianski $aokmians$ Fri, 30 Jun 2006 13:40:18 -0700

John:

The standards you listed define not just payload, but also the whole messaging. WSDM uses SOAP over HTTP. CIM-CX / WBEM - non-SOAP XML over HTTP.

I am not sure what we can add to help the above other than to say use TLS.

Or do you want syslog WG to provide an alternative messaging system, so you could do SOAP or CIM XML over syslog instead of HTTP? SOAP Envelopes within syslog messages sounds a bit of a stretch.

Could you give a rough, but specific example of what you have in mind for what syslog WG could produce to satisfy your goals?

Frankly, there will always be frameworks which will want to do eventing using their own protocol. For example, DSL Forum's TR-069 obsoletes all of SNMP and they are not relying on syslog. They uses their own SOAP-based framework for everything. Even if we provided a separate messaging system for syslog, why would they use it and deal with another protocol, more authentication, etc? So, I am am not sure how we can accommodate such frameworks.

Something that define pure payload, like IBM's CBE (XML messages), which they contributed to WSDM could be accommodated. Syslog-protocol supports any UTF-8 payload already.

Thanks,

Anton.

From: John Calcote [mailto:[EMAIL PROTECTED]
Sent: Friday, June 30, 2006 2:23 PM
To: Chris Lonvick (clonvick); David Harrington; 'Rainer Gerhards'; [EMAIL PROTECTED]
Subject: RE: [Syslog] Decisions to make about the Huawei IPR claim

Jumping in to add my two cents...

I quite agree with David on this point. If the syslog WG chose to begin work on network management issues, it would be stepping into a realm already well covered by other standards efforts. However - what the world does need is a standardized and widely understood and deployed _secure_transport_ for management events. One that will guarantee deliver and sequencing, as well as privacy based on administrative policy.

I work for Novell on the Audit Record Framework (ARF) - a part of the Bandit Project (http://www.bandit-project.org). ARF is chartered to provide an open source, portable, application audit instrumentation library based on existing standards work. We've chosen to use the OASIS WSDM Event Format - a W3C XML Schema-based approach. The ARF library will send management events over a secure protocol - hopefully syslog - to back-end event collection servers. Novell's eSecurity-acquired Sentinel product already listens on syslog (3195) channels for such event information. ARF will provide rich structured content from instrumented applications on this channel.

My suggestion would be for the syslog-sec WG to simply define the payload of syslog messages to be extensible and flexible, and not spend much time on defining the management content itself. With efforts like OASIS WSDM, DMTF CIM-XML (WBEM), and others already well underway, it makes no sense to go farther down this road with syslog - an event protocol whose charter makes it infeasible to try to cover the same amount of network management ground as these other standards efforts will.

John Calcote ([EMAIL PROTECTED])

Software Engineer/Architect

Novell, Inc.

>>> "David Harrington" <[EMAIL PROTECTED]> 6/30/2006 9:57 AM >>>
Hi,

[posting as a contributor]

I recommend this WG make a clear separation (as much as is possible)
between issues of security and issues of network management.

Issues such as harmonization with the work of other SDOs, integration
with netconf, message formatting, content standardization, and so on,
are about syslog as a network management protocol. I strongly beleve
this work should **not** be done by the syslog-sec WG, but in a WG
chartered in the OPS area or the Application area, not the Security
area. There are many contributors who have worked on, and are
currently working on, other network management protocols and have
addressed issues similar to those facing syslog.

In addition, there is an effort by the new OPS Management AD to
address the current isolated decision making (silos) that is occurring
regarding the management plane throughout the IETF. The contributors
to this WG should be involved in that discussion, which is likely to
be centered in the OPS area.

This WG is about security for syslog, and we should focus our efforts
on solving the security problems, whether with tls or ssh or beep, and
publish.

David Harrington
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]

> -----Original Message-----
> From: Rainer Gerhards [mailto:[EMAIL PROTECTED]
> Sent: Friday, June 30, 2006 6:11 AM
> To: David Harrington; Chris Lonvick; [EMAIL PROTECTED]
> Subject: RE: [Syslog] Decisions to make about the Huawei IPR claim
>
> David,
>
> I fully agree with your thought. I, too, think we must put emphasis
on
> the delivery of documents. In my personal opinion, this
> leaves only two
> realistic options:
>
> a) rfc 3195bis as you have described it (without the "rathole
> discussion")> b ) -transport-tls more or less as it is now
>
> I think there are enough comments on a) already in the list archive.
I
> will not repeat them.
>
> Comments on b) currently tend to focus on the IPR issue. Let's
ignore
> that for a moment and look at other arguments. We have
> intially opted in
> favor of -transport-tls because it already is in widespread
> use. What is
> done currently can not be standardized literally, but we can
> standardize
> something that is quite close to it. It was our opinion that
> -transport-tls should by fairly easy to implement, thus bringing
some
> immediate value to the community.
>
> Now some technical issues have come up on the list, things like
> app-layer ACKs, opening and closeing conversations. I have brought
up
> some of them. I am also of the view that we could craft a better
> framing, probably borrowing from NETCONF (and thus easing conversion
-
> the "big picture"). This is still sufficiently easy, but it is a big
> departure from the "let's standardize what is used in practice"
> approach. I fear that discussing a better framing/session management
> again takes up a lot of time and includes a high risk of missing our
> milestones again. BTW: we are scheduled to deliver by
> November 2006, and
> I do not expect that we will be granted an extension this time
again.
> November will be very soon, especially looking at the summer break.
>
> So I propose that we do NOT enter any new discussion. We
> should deliver
> either a) or b) (above), without introducing any new features
> or ideas.
> That means that the result will be sub-optimal. But
> delivering something
> usable is much better than aiming for the perfect one that will
never
> appear.
>
> Once we have delivered, we should discuss what to do next (but on! ly
&g t; AFTER delivery). I have to admit that I now see some good points in
a
> -transport-ssh and consider it implementable with reasonable effort.
> However, -transport-ssh should be done after we have reconsidered
the
> framing. Given the track record of this WG, I would suspect
> this can not
> be done in less than 12 to 24 month. There are also the issues that
> Anton brought up and the general question on configuration and event
> data models for syslog. A lot of useful work lying ahead (but
> depending
> on our ability to finish the base stuff first).
>
> I think this work can never be done if this WG fails. So I am
> desperately trying to get us to publish. I think what we have
> is useful
> and well-enough. If we do not publish soon, we will never be able to
> publish at all. IMHO, we have already received our third chance and
> there will be no fourth...
>
> Rainer
>
> > -----Original Message-----
> > From: David Harrington [mailto:[EMAIL PROTECTED]
> > Sent: Thursday, June 29, 2006 8:32 PM
> > To: Rainer Gerhards; 'Chris Lonvick'; [EMAIL PROTECTED]
> > Subject: RE: [Syslog] Decisions to make about the Huawei IPR claim
> >
> > Hi Rainer,
> >
> > [speaking as a contributor]
> >
> > This WG needs to deliver documents soon or the WG could be closed.

> > We need to deliver a secure transport solution.
> > If the WG decides to do a 3195bis as the secure transport
> solution, I
> > recommend the short-term deliverable be "good enough" to work with
> > syslog-protocol. That way we can get 3195bis AND the other
documents
> > (-protocol- and -udp-) published and onto the standards
> track, so the
> > industry can begin to implement, and the WG can stay open to do
> > additional work.
> > > &g t; Then we can address whether the 3195 design should be modified in
> > other ways. There have been suggestions to modify 3195 to
> "harmonize"
> > with the work of other Standards Development Organizations such as
> > OASIS and W3C. Doing that work would likely not be quick or easy.
I
> > fear it would be a real rathole that would prevent us
> getting 3195bis
> > published at all, and if 3195bis is the WG's choice as the secure
> > transport protocol, then that rathole would also prevent the
> > publication of -protocol- and -udp- on a timely basis.
> >
> > As a 14-year veteran of IETF WG efforts, I think it would
> be a bad WG
> > decision to put 3195bis on the critical path and to open it up to
a
> > rathole discussion. If 3195bis is on the critical path, we need to
> > avoid the rathole discussion for now; it can be considered for a
> > future "release". If the WG feels the rathole discussion is really
> > necessary, and 3195bis should not be done without having had such
a
> > possible-rathole discussion, then 3195bis should not be put on the
> > critical path.
> >
> > My $.02
> > David Harrington
> > [EMAIL PROTECTED]
> >
> >
> > > -----Original Message-----
> > > From: Rainer Gerhards [mailto:[EMAIL PROTECTED]
> > > Sent: Thursday, June 29, 2006 5:11 AM
> > > To: Chris Lonvick; [EMAIL PROTECTED]
> > > Subject: RE: [Syslog] Decisions to make about the Huawei IPR
claim
> > >
> > > Besides the somewhat political issue, I think there is also
> > technical
> > > issue that affects the question. I think we should consider that
> > > question in parallel to the IPR question.
> > >
> > > This question is if this WG intends to! do a re vision of 3195.
And,
> > if
> > > so, I think the very close next question is if we "just" update
it
> > to
> > > support syslog-protocol or if we intend to make any
> > > substantial changes.
> > >
> > > I see a relationship between the IPR and the 3195bis issue
because
> > > 3195bis modifies the "cost" of finding alternate solutions.
Coming
> > to
> > > this point, it would probably be helpful if we could actually
> > > weigh cost
> > > vs. utlity of the different approaches. IPR, IMHO, is just a
cost,
> > > obviously one whose weight we need to decide on. But I think it
is
> > not
> > > the only cost. If the WG finds such a "cost vs. utility"
> discussion
> > > useful, I could document my point of view as a starting point. I
> > > volunteer to create a summary document (a public web page, not a
> > I-D)
> > > where I track all contributions to this discussion (for an
example
> > of
> > > what I have in mind see Juergen Schoenwaelder's page on netconf
> > > notification requirements:
> > >
> http://www.eecs.iu-bremen.de/wiki/index.php/Netconf_notifications).
> > >
> > > I would find such a page very helpful. It documents the
> > > decision process
> > > and the decision criteria. In doing that, it helps us come to a
> > better
> > > decison because we than have all facts at a single place.
> > > Thus, it also
> > > provides good argument when dealing with the IESG (in the case
we
> > need
> > > to justify the decision).
> > >
> > > Thanks,
> > > Rainer
> > >
> > > > -----Original Message-----
! > > ; > > From: Chris Lonvick [mailto:[EMAIL PROTECTED]
> > > > Sent: Wednesday, June 28, 2006 7:56 PM
> > > > To: [EMAIL PROTECTED]
> > > > Subject: [Syslog] Decisions to make about the Huawei IPR claim
> > > >
> > > > Hi Folks,
> > > >
> > > > It's looking like we have a primary decision to make about
> > > > the IPR claim
> > > > that Huawei has made on syslog-transport-tls. First and
> > > > foremost, I want
> > > > everyone to be informed of the IETF stand on IPR claims and
> > > > on the IETF
> > > > process that we will follow.
> > > >
> > > > This is the position of the IETF on IPR claims:
> > > > --------------------------------------------------------------
> > > > -----------
> > > > Intellectual Property
> > > >
> > > >     The IETF takes no position regarding the validity or
> > > scope of any
> > > >     Intellectual Property Rights or other rights that might
> > > > be claimed to
> > > >     pertain to the implementation or use of the technology
> > > > described in
> > > >     this document or the extent to which any license under
> > > such rights
> > > >     might or might not be available; nor does it represent
> > > that it has
> > > >     made any independent effort to identify any such rights.
> > > > Information
> > > >     on the procedures with respect to rights in RFC
> documents can
> > be
> > > >   &nb! sp; foun d in BCP 78 and BCP 79.
> > > >
> > > >     Copies of IPR disclosures made to the IETF
> Secretariat and any
> > > >     assurances of licenses to be made available, or the
> result of
> > an
> > > >     attempt made to obtain a general license or permission
> > > > for the use of
> > > >     such proprietary rights by implementers or users of this
> > > >     specification can be obtained from the IETF on-line IPR
> > > > repository at
> > > >     http://www.ietf.org/ipr.
> > > >
> > > >     The IETF invites any interested party to bring to its
> > > > attention any
> > > >     copyrights, patents or patent applications, or other
> > proprietary
> > > >     rights that may cover technology that may be required
> > > to implement
> > > >     this standard. Please address the information to
> the IETF at
> > > >     [EMAIL PROTECTED]
> > > > --------------------------------------------------------------
> > > > -----------
> > > > This is at the bottom of all RFCs. It's pretty clear that we
> > > > (our Working
> > > > Group) has no place to appeal claims of IPR to.
> > > >
> > > > Also, the more detailed explanation of the IETF position is
> > > in BCP 79:
> > > >    http://www.ietf.org/rfc/rfc3979.txt
> > > > I will ask that everyone! read th rough this before
> expressing their
> >
> > > > opinion.
> > > >
> > > > One additional source of information for our process is
> RFC 3669:
> > > >    http://www.ietf.org/rfc/rfc3669.txt
> > > > "Guidelines for Working Groups on Intellectual Property
Issues"
> > > > --------------------------------------------------------------
> > > > -----------
> > > > 1. Introduction
> > > >
> > > >     This memo lays out a conceptual framework and rules of
thumb
> > to
> > > >     assist working groups dealing with IPR issues. The
> goal is to
> > > >     achieve a balance between the needs of IPR claimants and
the
> > > >     implementers of IETF standards which is appropriate to
> > > > current times.
> > > >     As part of trying to distill out principles for dealing
> > > > with IPR in
> > > >     IETF working groups, it provides case studies of
> > > working group IPR
> > > >     treatment. In other words, it documents the running code
> > > > of the IETF
> > > >     process.
> > > >
> > > >     This memo does not describe IPR procedures for document
> > > authors or
> > > >     IPR claimants. Those are covered in two other memos, on
> > > > submission
> > > >     rights [5] and IPR in the IETF [6]. Rather, this memo is
> > > > for work! ing
& gt; > > >     groups that are trying to decide what to do about
technology
> > > >     contributions which have associated IPR claims.
> > > > --------------------------------------------------------------
> > > > -----------
> > > > [5] and [6] are BCP78 and BCP79 respecively.
> > > > This document contains a lot of really good advice that we
> > > > should be aware
> > > > of while we make our decision.
> > > >
> > > > One part of RFC 3669 is a recommendation to take a critical
> > > > look at the
> > > > terms of the claim - Section 5.6. Essentially, if we can get
> > > > consensus
> > > > that the terms are acceptable for implementation, then the
> > > > IPR claim may
> > > > not be an issue - we can continue to progress
> > > > syslog-transport-tls. On
> > > > the other hand, if the terms are not acceptable then we can't
> > > > expect any
> > > > implementations.
> > > >
> > > > I'm going to ask that everyone please start considering these
> > > > inputs and
> > > > openly discuss your thoughts about the IETF process and the
> > options
> > > > available to our Working Group on the mailing list.
> > > > +++ +++ +++ +++ +++ +++ +++ +++ +++
> > > >    Do not declare your opinion yet.
> > > > +++ +++ +++ +++ +++ +++ +++ +++ +++
> > > > In a week or so I will ask the group to decide how we should
> > > > process. I
> > > > want everyone to take the time now to get acquainted with the
> > > > process and
> > > > the inf! ormation that we have available to us.
> > > >
> > > > I believe that ultimately, we will need to decide on whether
> > > > to continue
> > > > to progress syslog-transport-tls, or if we will want to
> > > > accept a different
> > > > path. If we start down a new path, then we will still need
> > > > to make sure
> > > > that we are meeting the security objectives that we feel are
> > > > important.
> > > > This discussion has already been started, which is good in
> > > that it can
> > > > bringing to light some of the issues that need to be
> > > > discussed around the
> > > > secure transport of syslog. Once we get this primary issue
> > > > resolved then
> > > > we can decide upon that.
> > > >
> > > > Also, the Milestone about delivering a TLS solution can be
> > > > easily changed.
> > > > I did submit it that way to the IESG and Tom Petch noted that
> > > > the Charter
> > > > just said "security" protocol while the Goal specified
> a specific
> > > > solution. Sam didn't want to change it after it had gone
> > > in but I'm
> > > > certain that it's not going to be a problem if we do want to
> > > > change it.
> > > >
> > > > Thanks,
> > > > Chris
> > > >
> > > > _______________________________________________
> > > > Syslog mailing list
> > > > [email protected]
> > > > https://www1.ietf.org/mailman/listinfo/syslog
> > > >
> > >
> > > _______________________! ________ ________________
> > > Syslog mailing list
> > > [email protected]
> > > https://www1.ietf.org/mailman/listinfo/syslog
> > >
> >
> >
>

_______________________________________________
Syslog mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/syslog

_______________________________________________
Syslog mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/syslog

RE: [Syslog] Decisions to make about the Huawei IPR claim

Reply via email to